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The design and execution of a networked virtual environment (NVE) are 
challenging tasks made even more difficult by the fact that NVEs are becoming more 
complex and difficult to manage. In a distributed environment, each simulation not only 
computes its own behaviors and publishes them to the network, but it must accurately 
represent all other entities participating in the NVE. To simplify this task, this thesis 
implements method to make distributed simulations dynamically extensible, flexible, 
specific, and consistent. Bamboo provides the ability to dynamically extend the virtual 
environment by defining a convention by which plug in modules can be added during 
simulation runtime. The HLA provides the network communication layer that transports 
entity state updates to all members of the distributed simulation. These two tools combine 
to create a unique solution to problems inherent in designing modem networked virtual 
environments. The implementation is dynamically extensible which increases the flexibility 
implementers have in designing virtual environments. The HLA transports the entity 
updates and the module name that must be used to represent the entity. This method 
allows programmers to design only their module because modules representing other 
entities will load as needed during the execution. This method of implementing virtual 
environments that promises to streamline the design and implementation process. 
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I. INTRODUCTION 



A. MOTIVATION 

The design and execution of a networked virtual environment (NVE) are 
challenging tasks made even more difficult by the fact that NVEs are becoming more 
complex and difficult to manage. In a distributed environment, each simulation not only 
computes its own behaviors and publishes them to the network, but it must accurately 
represent all other entities participating in the NVE. To simplify this task, a method must 
be devised to make distributed simulations dynamically extensible, flexible, specific, and 
consistent. A dynamically extensible virtual environment would allow users to change the 
executable at runtime to whatever state is specified by the user. The challenge is to design 
a system that allows users to design entity definitions that can be loaded and unloaded 
during execution. With true dynamic extensibility comes flexibility, and designers are not 
tied to compile time determinations of behavior. Consistency in this sense means all sites 
participating in the NVE need the same definitions for each entity and the terrain model 
being used. Finally, the designer of a specific simulation, such as a tank simulator, should 
not need to design the other entities that will be depicted in the simulation. These remote 
objects should be program objects that can be added as needed during execution. This 
approach will allow NVE implementers and programmers the flexibility to design and run 
NVEs in real time without the problems of inflexibility and static design inherent to 
distributed simulation. 

B. BACKGROUND 

There are many examples of NVEs that use different methods of communicating 
entity state and ensuring consistency between simulation locations. Examples include 
DIVE [1] and BRICKNET [2]. These systems share one characteristic. They are defined 
at compile time and are unchangeable during execution. They allow dynamic allocation of 
memory but the definitions of each entity are defined at compile time and are 
unchangeable. 

The DIVE core uses peer-to-peer communication between shared virtual worlds. 
All DIVE processes connected to the same world are identical. A DIVE process can 
choose what world it is a part of but it can only be a member of one world at a time. 
DIVE is limited by the paradigm of distributed, shared memory. This paradigm creates 
significant network traffic trying to keep the shared memory consistent from process to 
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process. While DIVE shared virtual worlds may change during runtime, the method of 
communication and the abilities of the system are previously defined and are not extensible 
at runtime. 

BRICKNET allows the exchange of objects and object updates through 
BRICKNET servers. While it does distribute processing on multiple servers, entities 
require the server to update state and define behavior. Workstations are primarily used to 
render the graphics for the user. Furthermore, BRICKNET object updates are predefined 
and the update protocol cannot be modified. 

Finally, distributed interactive systems (DIS) like NPSNET [3] are designed on the 
premise that each site could build their own simulation and choose how to represent each 
type of entity without regard to the consistency of this representation across the network. 
Each site could have its own terrain model and its own representations for each entity 
type. Because of these inconsistencies, DIS simulations are plagued with discrepancies 
between entity position and orientation and line of site computations related to the terrain 
models. DIS is highly enumerated and the packets containing entity state are large and 
mostly redundant. These inconsistencies complicate interactions between entities because 
the terrain may provide different line of sight computations from one simulation to the 
next. Additionally, the actual polygonal representation and behaviors of the entity may not 
be consistent among workstations in the distributed simulation. This causes excess 
network traffic to solve simple interactions between entities and keep entity state updated 
accurately between simulation sites. 

Until now, there was no way to ensure all simulation sites had the proper 
polygonal and behavioral representation for all entities participating in the virtual 
environment. A new system. Bamboo [4], provides such a capability by providing 
simulations a framework to dynamically load and unload program modules as the situation 
changes in the virtual environment. High Level Architecture (HLA) [5] replaces DIS and 
provides the network communication capabilities. By implementing the simulation as a 
group of program modules, designers solve the problem of ensuring that every site running 
in the NVE is consistent with every other. The designer just ensures every participant in 
the NVE knows the network location of all the program modules making up the NVE. 
Then, as the virtual world executes, each site loads and unloads modules as needed. All 
simulation sites have the same representations for each entity as well as its associated 
behaviors and controls. 

This thesis describes an implementation that uses Bamboo to handle the dynamic 
nature of modem NVEs, and HLA to handle the communication between each simulation 
site. The following sections provide an overview of Bamboo and HLA features and how 
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they apply to this implementation. Later chapters provide a detailed description of both 
systems. 

C. BAMBOO 

Bamboo enables dynamically scaleable virtual environments hosted on a network. 
It achieves this goal by an efficient implementation that provides direct support for the key 
issues pertaining to VE development. These issues include dynamic extensibility, module 
dependency, and event handling [4], Bamboo’s most notable feature is its ability to 
dynamically extend its capabilities during run time. It achieves this goal by implementing a 
plug-in metaphor similar to that used by commercial packages like PhotoShop [6] and 
Netscape [7]. In addition to the plug-in metaphor, Bamboo implements a system that 
allows the user to extend the executable through a series of callbacks that a newly added 
module allocates at load time. The event handler simply provides an abstraction for 
handling system-generated events. The event handler uses the callback handler to notify 
registered parties of an event. Bamboo receives this notification as a callback. Module 
dependency provides a system to ensure that modules which are required by other 
modules are loaded first before the depending module. Bamboo uses callback handlers so 
multiple callbacks respond to a single event. This is a cursory introduction to the features 
and capabilities of Bamboo. Chapter two provides a detailed description of the Bamboo 
system. 

D. HIGH LEVEL ARCHITECTURE 

The High Level Architecture (HLA) is the Department of Defense standard for 
simulation interoperability [5]. HLA is not software. It is an architecture that provides 
standard methods of defining how distributed simulations will communicate. It is a set of 
specifications that define data objects. These standards are specified in the HLA Interface 
Specification and the Object Model Template (OMT). The HLA Interface Specification 
defines the interface between the simulation and the software that will provide the network 
and simulation management services. The Runtime Infrastructure (RTI) is the software 
that provides these services. The OMT prescribes a common method for recording the 
information that will be produced and communicated by each simulation participating in 
the distributed exercise. This discussion of HLA is continued in detail in Chapter 3. 

E. THESIS ORGANIZATION 

This thesis is organized into the following chapters: 
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• Chapter I: Introduction. Outlines the organization of the thesis and addresses 
the significance of introducing and evaluating a new method for implementing 
a networked virtual environment. 

• Chapter II: Bamboo. Discusses in detail the current implementation of 
Bamboo and how its capabilities are suited for a networked virtual 
environment implementation. 

• Chapter III: High Level Architecture. Discusses in detail the current 
implementation of the HLA and how its capabilities are suited for a networked 
virtual environment implementation. This chapter includes a detailed 
discussion of the run time infrastructure (RTI) and how its capabilities are 
exploited in this implementation. 

• Chapter IV: Implementation. Describes the development of the experimental 
virtual environment that illustrates the power of combining Bamboo and HLA. 

• Chapter V: Results and Limitations. Describes performance results for the 
implementation and certain limitations discovered during development. 

• Chapter VI: Conclusions and Recommendations. Discusses the significance of 
the results and gives ideas as to future work that should be completed in this 
area. 
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II. BAMBOO 



A. INTRODUCTION 

Bamboo enables dynamically scalable virtual environments hosted on a network 
[4]. It achieves this goal by an efficient implementation that provides direct support for 
the key issues pertaining to VE development. These issues include dynamic extensibility, 
event handling, and module dependency. By addressing these issues, Bamboo provides 
the ability for the system to dynamically configure itself during runtime. Specifically, this 
framework provides the ability to discover simulation objects on the network at runtime 
and automatically load the correct module to represent the entity. 

B. DYNAMIC EXTENSIBILITY 

Bamboo’s most notable feature is its ability to dynamically extend its capabilities 
during run time. It achieves this goal by implementing a plug-in metaphor, then extends 
the idea by adding module dependency, a generalized method of extending the executable 
and a generalized event handler. 

1. Dependency 

Bamboo extends the plug-in metaphor by adding inter-module dependencies. 
Tracking inter-module dependencies could be complex. Fortunately, as Bamboo loads 
each module, it verifies that dependent modules load first. If they are not loaded, it 
automatically loads them without specific interaction with the user. Using Figure 1 as an 
example, assume M3 is already loaded. If M4 loads later, the system verifies the presence 
of M2 in memory. Bamboo loads M2 if it is not in memory. As M2 is being loaded 
Bamboo verifies the presence of Ml. M4 finally loads because Bamboo verified all its 
dependencies [4], 
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2. Extending the Executable 

Dynamic loading of program modules does not in itself ensure dynamic 
extensibility. Bamboo uses a callback handler that allows each module to attach and 
remove itself from the process’s execution loop when being paged in and out of memory. 
The callback handler derives from objects that can be named so it is easily located and 
manipulated. The callback itself is recursive and provides two callback handlers, one just 
before callback execution and one directly after. This allows grouping of like 
functionality. For example, rendering engines implement some form of app, cull and draw 
as a pipeline. Users refer to surrounding areas as pre and post app, pre and post cull, and 
pre and post draw. The executable begins to resemble a tree of callbacks. Figure 2 
illustrates how using callbacks and callback handlers to extend the executable begins to 
resemble a tree of callbacks. For instance, a user module may load itself and depend to 
the visual and keyboard modules. At load time, the user module defines callbacks that 
provide execution time for the logic in the module. Furthermore, any pruning or pausing 
of sub-trees automatically includes its children. Therefore if a callback handler is deleted, 
all of its associated callbacks are also deleted without specific user interaction. 
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Figure 2: Extending the Executable 

3. Event Handling 

The event handler simply provides an abstraction for handling system-generated 
events. The event handler uses the callback handler to notify registered parties of an 
event. Bamboo receives this notification as a callback. Bamboo uses callback handlers so 
multiple callbacks respond to a single event. For example, a module that captures 
keyboard events would monitor the keyboard in a separate thread listening for keys 
identified by the user. In figure 2, the Event Handler Module has multiple callbacks on 
two separate keys. When a key is pressed, then the callbacks are executed in the order 
specified. 

C. BAMBOO CONCLUSION 

Bamboo improves on the plug-in metaphor in three distinct ways. It provides a 
convention for the definition of program modules. Second, it generalizes a method to 
extend the executable, and third, it provides a method to build dependencies between 
modules. Using these features. Bamboo overcomes many of the pitfalls of monolithic 
virtual environment architectures by providing modular components and a dynamically 
extensible runtime executable. 



7 













































8 



III. HIGH LEVEL ARCHITECTURE 



A. INTRODUCTION 

The High Level Architecture (HLA) provides a common architecture for reuse and 
interoperation of simulations. This means that simulations designed for a specific purpose 
may be reused in a different application using che HLA concept of a federation: a 
composable set of interacting simulation participants - federates. The intent is to provide 
a standard architecture under which simulations are designed so that they can be reused 
thereby reducing the time and cost required creating a new environment for a new 
purpose. [5] 

The Object Model template (OMT) [8], HLA rules [9] and the Interface 
Specification (IF Spec) [10] define the HLA standard. A final component of the HLA is 
the Runtime Infrastructure (RTI). The OMT describes the essential sharable elements of 
the simulation or federation in ‘object’ terms. In the HLA sense, objects are collections of 
attributes that describe simulation entity state that are communicated between federates 
operating in the federation. Second, the IF Spec describes the runtime services provided 
to each federate by the RTI. The RTI is the software component of the HLA that 
supports the exchange of data defined by the OMT component. Finally, The HLA rules 
summarize the key principles behind the HLA. 

B. OBJECT MODEL TEMPLATE 

The HLA is designed to facilitate interoperability. Hence, the OMT is designed to 
provide a means for open information sharing across the simulation community. The 
OMT does not constrain the content, but provides a streamlined format for 
communicating to the other users, who may reuse the simulation, and the data inputs and 
outputs of the simulation. The HLA specifies two types of object models: the HLA 
Federation Object Model (FOM) and the HLA Simulation Object Model (SOM). The 
FOM is a specification of the exchange of public data among the participants in a HLA 
federation. Those participants are called federates. The HLA FOM describes the set of 
objects, their attributes and interactions that are shared between federates in a federation. 
The SOM describes the simulation (federate) in terms of the types of objects, attributes, 
and interactions it can offer to future federations. 
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1 . 



Federation Object Model 



The FOM requires information concerning the object classes, object interactions, 
class attributes, interaction parameters and a lexicon describing each of the above [8]. 

a. Object Class Structure Table 

Each object class must be named and its relationship to other classes must 
be defined. All classes must be defined and described in the lexicon. The result is a table 
similar to Table 1 [8]. 



Object Class Structure Table 


<class>(<ps >) 


[<class> (<ps>)] 


[<class> (<ps>)1 


f<class> (<ps>)] [.<class>(<ps>)]*l f<re£>] 


[<class> (<ps>)l 


[<class> (<ps>)] [,<class>(<ps>)]*l f<ref>] 


... 


— 


f<class> (<ps>)] 


[<class> (<ps>)l [,<class>(<ps>)l*l f<ref>l 


(<class> (<ps>)] 


f<class> (<ds>)1 


f<class> (<ps>)1 f,<class>(<ps>)l*l f<re£>] 






[<class> (<ps>)1 


f<class> (<ds>)1 f,<class> (<ps>)l*l f<ref>1 








<class>(<ps>) 


[<class> (<ps>)] 


f<class> (<ds>)1 


[<class> (<ds>) 1 f.<class> (<DS>)l*II<re£>l 


[<class> (<ps>)l 


f<class> (<ps>)l f,<class> (<ps>)1*l f<re£>] 










- 


- 




Air Vehiclc(S) 


Fixed Wing (S) 


Fighter-Attack (S) 


F-14 (PS) 


F-16 (PS) 


F-18 (PS) 


Bomber (S) 


B-1B(P$) 


B-2 (PS) 


Rotary Wing (PS) 







Table 1: Object Class Structure Table 

This table shows the object model used in a federation. Class Air Vehicle is the base class 
for all flying entities. Class Fixed Wing and Rotary wing inherit from Air Vehicle, while 
Fighter-Attack and Bomber inherit from Fixed Wing. Then F-14, F-16, etc. describe the 
specific types of aircraft depicted in the federation. The (P), (S) and (PS) stand for 
publishable, subscribable and both, respectively. This means that individual federates can 
request - subscribe - certain object attributes from the federation. A federate may also 
provide - publish - object attributes to the federation. If a federate represents an entity 
that must interact with entities of the same type, that federate might publish and subscribe 
to the same Object Class. 
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b. Object Interaction Table 

The object interaction table shows the interaction class structure for the 
federation. Table 2 shows the interaction class structure [8], An interaction is an explicit 
action taken by an object that can optionally be directed toward other objects. In this 
case. Weapon Detonate is the base interaction class, and Weapon Detonate at Air Target 
and Weapon Detonate at Ground Target arc both inherited from Weapon Detonate. This 
table also lists the initiating and receiving object and the affected attributes for each object. 



Object Interaction Table 


Interaction Structure 


Initiating Object 


Receiving Object/ Area 


Interaction 

Para meters 


Intt/ 

Sense/ 

React 


Class 


Affected 

Attributes 


Class 


Affected 

Attributes 


<interact>on> 


[<mteraction>] 


<class> 

[.<clas3>p 


[<attnbute>] 

[,<attnbute>r 

[(<commem>)]‘ 


[<clas3>] 

(.<das3»j* 


[<attnbute>] 

[.cattnbute^ 

[(<£orrment>)]* 


[<parameter>) 

[.<param«ter>r 


<isr> 


(interact ion>] 


<class> 


[<attnbute>] 

(.<artnbuie>r 

[{<comment>)]* 


[<dass>] 

(.<class»r 


[<attnbuie>] 

r.<attnbute>r 

[(<comment>)]* 


(<parameter>] 

[.<parameter>J* 


<«/> 


_ 


.. 


_ 


- 


- 


- 


- 


<interaction> 


[interact ron>] 


<elass> 

[.<de«3>r 


[<altrtoute>] 

[.<aflr4>ute>]‘ 

[{ccomment>)]* 


[<dass>] 

(,<dass>j* 


(<attnbute>) 

[.<artrfcute>j* 

[(<comment>)I* 


[<parameter>] 

(,<parameter>j* 


<«r> 


- 


- 


- 


- 


- 


- 


- 


- 




Weapon 

Detonate 


Weapon Detonate 
at Ajr Target 


Weapon 


Velocity. 

Acceleration. 

Weight, 


Air Vehele 


Velocity. 

Acceleration. 

Weight, 


Weapon Location. 

Warhead. 
Weapon Attitude. 


in 


Weapon Detonate 
al Ground Target 















Table 2: Object Interaction Table 

The last column in the table shows the three basic categories of interaction: 

• Initiates (I): indicates that a federate is currently capable of initiating and sending 
interactions of the type specified in that row. 

• Senses (S): indicates that a federate is currently capable of subscribing to the interaction 
and utilizing the interaction information, without necessarily being able to effect the 
appropriate changes to affected objects. 

• Reacts (R): indicates that federate is currently capable of subscribing and properly 
reacting to the interactions of the type specified by effecting the appropriate changes to 
any owned attributes of the affected objects. 

In a FOM definition, all of the above are valid entries. There would not be a listing if 
there was not a federate responsible for the interaction. 
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a. Attribute/Parameter Table 

Finally, the Attribute/Parameter Table [8] defines characteristics pertinent 
to each Class/Interaction described in Table 1 and Table 2. Interactions are published by 
and subscribed to by federates depending on the structure of the federation. Table 3 is the 
Attribute/Parameter Table for a Tank Object and the Weapon Detonate Interaction. For 
each Object/Interaction the 



Object/ 
In tv act km 


AttirtbuW 

Parameter 


Data 

Typa 


Cardinality 


Units 


Resolution 


Accuracy 


Accuracy 

Condition 


Update 

Type 


UpOSd 

Condition 


T/A 




<dass> 1 
< Interact io ro 


<attnbuie>l 

<parameter> 


< data type > 


[<size>] 


<unrts> 


<resoluton> 


<aocuracy> 


<oond«K3n> 


<type> 


<rale> 1 
<oondrt)on> 


<ia> 


<ur> 


<atmbuie>l 

<parameter> 


<datatype> 


(<sae>] 


<unrts> 


<resolutorc» 


<accuracy> 


< condition;. 


<type> 


<rale> 1 
<oondrt)on> 


<ta> 


<ur> 






(<sae>] 


















<dass> l 
<ln1eracbon> 


<attnbuie>l 

<parameter> 


<datatype> 


[<sce>] 


<unrts> 


cresoluloro 


<aocuracy> 


<oondition> 


<type> 


<rate> 1 
<condfbon> 


<ta> 


<ur> 


<attnbute>l 

<parameteo 


<dataffype> 


[<sce>] 


<units> 


<resolu1crT> 


<accuracy> 


<coodtfcort> 


<type> 


<rate> 1 
<oondrtion> 


<ta> 


<ur> 




... 


[<sne>] 


















<class> 1 
< Interaction* 


<aftrbute>l 

<peramet©r> 


<dalatype> 


[<soe>] 


<units> 


<resolut»on> 


<ac<xracy> 


<ccnditiorc* 


<typa> 


<rate> 1 
<oondrtKxi> 


<ta> 


<ur> 








[<soe>] 


... 










- 


- 






Tenk 


Aree 


Float 


1 1 m2 


0.1 m2 


perfect 


always (ooodrtcnel 


seen events 


TA 


UR 


Velocity 


Double 


1 


m/sec 


1 m/sec 


.01 nVsac 


none 


periodk: 


10 Hz 


TA 


UR 


State 


Tank_Type 


1 


rVe 


fVa 


n/e 


fVe 


coocfctcnel 


seen events 


TA 


UR 


Position 


Rectng_Type 


1 


rVe 


rVe 


n/e 


fVa 


periotic 


10HZ 


TA 


UR 


Weapon 

Detonate 


Warhead 


Wh_Type 


1 


fVa 


rVe 


fVe 


fVa 


rv'a 


rVe 


n/a 


rVe 



Table 3: Attribute/Parameter Table 



attributes or parameters are defined and characterized by multiple descriptors like data 
type and units of measure. The second to last column, Transfer able/ Acceptable refers to a 
federate’s ability to transfer or accept the responsibility to update the specified attributes 
for a particular entity. For a FOM, the only acceptable entries are (TA) for 
Transferable/ Acceptable or (N) for Not Transferable/Acceptable. The last column refers 
to a federate’s capability to update (U) and reflect (R) attributes or parameters. In a 
FOM, all attributes or parameters should be marked both updatable and reflectable. 
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2 . 



Simulation Object Model 



A FOM is the union of all SOMs used to define the federation. The SOM uses the 
same templates as the FOM. The Object Class Table in Table 1 describes the object 
classes represented in the federation. A SOM object class structure table would designate 
which classes the federate publishes (P) and which it has the capability to subscribe (S). 
For example, the F-16 federate might publish the F-16 object and subscribe to air vehicle 
so it would know the location and speed of all other aircraft in the federation. Similarly, 
the Object Interaction table would differ in the last column because the federate must 
identify what interactions it has the capability to process. The F-16 federate might put a 
(R) in the last column of Table 2 to indicate that it reacts to a Weapon Detonation at an 
Air Target. Additionally, a (I) might go in the last column for Weapon Detonate at 
Ground Target to show that the F-16 federate initiates the interaction to fire weapons at a 
ground target. Finally, the last two columns in the Attribute/Parameter Table would be 
modified to show what capabilities the federate has in regards to its ability to transfer and 
accept attributes or update and reflect attributes. 

3. FOM/SOM Lexicon 

To achieve interoperability between simulations, all data required by the federation 
must be fully explained. It is not enough to merely specify the classes of data required by 
the templates above. The semantics of this data must also be explained. The FOM/SOM 
Lexicon provides a means for federations to document the definitions of all terms utilized 
during construction of FOMs, and for individual federates to document the definitions of 
all terms provided in their SOMs. 

C. INTERFACE SPECIFICATION 

The IF Spec [9] describes the runtime services provided to the federates by the 
RTI, and from the federates to the RTI. There are six classes of service. Each defines a 
specific set of functions that pertain to a particular type of transaction that must be 
accomplished to properly manage the federation. There are two locations where the 
function definitions reside: the RTI ambassador and the federate ambassador. The RTI 
ambassador is the software component provided by HLA and contains all the functionality 
required to accomplish communication to the network. The federate ambassador is the 
RTFs interface to the federate. To pass data to the federate, the RTI ambassador makes 
function calls to a user defined federate ambassador. The RTI ambassador is the same for 
all federates but the federate ambassador is different for each federate. A full explanation 
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of each function can be found in the HLA IF Spec. The following discussion deals mainly 
with the purpose of each management service. 

1. Federation Management 

Federation management services offer the basic functions required to initiate the 
federation, add federates and delete federates as the federation finishes execution. These 
services include Create, Join, Pause/Resume, Resign and Destroy federation. 

2. Declaration Management 

Declaration management defines the services required to support efficient 
management of data exchange. It does this by providing the services that allow federate’s 
to identify to the RTI ambassador the object and interaction classes they will publish and 
subscribe. This service includes Publish, Subscribe, and Control actions on specific object 
classes and interactions. 

3. Object Management 

Object management services refer to all the functions required to manage the 
update of object attributes during federation execution. The services include Request 
Object ID numbers. Update object attributes. Sending Interactions, Receiving object 
updates. Receiving interactions, Deleting objects and Changing transportation 
characteristics. 

4. Ownership Management 

Ownership management refers to the dynamic transfer of ownership of object 
attributes during federation execution. The services include Request attribute ownership, 
Divest Attribute ownership and Release attribute ownership. 

5. Time Management 

Time management services support the synchronization of runtime simulation data 
exchange. The current HLA time management service provides support for time-step and 
event-driven simulation systems but support for platform level real-time simulations is 
limited to wall clock time. 
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6 . 



Data Distribution Management 



Data distribution management supports the efficient routing of data among 
federates during the course of a federation execution. This service allows federates to 
identify regions of interest and limit attribute to entities that fall into those regions. 

D. HLA RULES 

There are ten basic rules that define the responsibilities and relationships between 
HLA federates and the federation. There are ten rules: five rules apply to federations and 
five rules apply to federates [10]. 

1. Federation Rules 

• Rule 1: Federations shall have an HLA FOM, documented in accordance with the 

HLAOMT. 

• Rule 2: In a federation, all object representation shall be in the federates, not in the 

runtime infrastructure. This means that the RTI cannot be used to track entity state. All 
entity representations are defined by the federate and communicated to other federates via 
the RTI. 

• Rule 3: During a federation execution, all exchanges of FOM data among federates 

shall occur via the RTI. 

• Rule 4: During a federation execution, federates shall interact with the RTI in 

accordance with the HLA IF Spec. The only way to interface with the RTI is through the 
RTI ambassador and the services provided in that class 

• Rule 5: During a federation execution, an attribute of an instance of an object shall 

be owned by only one federate at any given time. No attribute can be published by more 
than one federate at a time. 



2. Federate Rules 

• Rule 6: Federates shall have an HLA SOM documented in accordance with the 

HLA OMT. Each simulation must describe the functionality it will provide to the 
federation. The federation is not required to use all the functionality supplied by the 
federate. 

• Rule 7: Federates shall be able to update and/or reflect any attributes of objects in 

their SOM and send and/or receive SOM object interactions externally, as specified in their 
SOM. 

• Rule 8: Federates shall be able to transfer and/or accept ownership of attributes 

dynamically during a federation execution, as specified in their SOM. 
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• Rule 9: Federates shall be able to vary the conditions (e.g., thresholds) under which 

they provide updates of attributes of objects, as specified in their SOM. 

• Rule 10: Federates shall be able to manage local time in a way that will allow them 

to coordinate data exchange with other members of a federation. Non-time managed 
federates manage time internally in their own way, but time managed federates must manage 
time in such a way so it appears there is only one clock. 



E. HLA CONCLUSION 

The HLA architecture is designed to improve the method of simulation interaction 
by making certain types of simulation systems reusable among disparate simulation 
applications. It accomplishes this goal by providing a standard method of communicating 
simulation capabilities (SOM) and a standard method of defining how those simulations 
will communicate on the network (FOM). The RTI provides the communications link to 
manage the operation of a federation using the IF Spec. The HLA rules link it all together 
by providing guidelines that ensure designers will use all the components is such a way as 
to accomplish the goal of reusable inter-operating simulations 
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IV. IMPLEMENTATION 



A. INTRODUCTION 

The goal is to provide a dynamic, flexible, and consistent environment for three- 
dimensional networked virtual environments. Consistency is accomplished by ensuring all 
modules are available locally or via the network from a centralized location. As the 
simulation executes, users decide which terrain module to use and which simulation 
entities will populate the environment. Bamboo provides the ability to dynamically load 
and unload modules. The ability to add a module provides dynamic extensibility. It is the 
ability to unload modules that makes the system flexible. Flexibility requires that the 
implementers can change the virtual environment on the fly without restarting. 

To this end, the implementation has three major components: the HLA 
administration module (amHLAAdmin), entity modules, and terrain modules. The 
amHLAAdmin module manages the communication layer (RTI), module loading and 
unloading, and all participating entity objects. Each entity module represents the behavior 
and polygonal representation for each entity. The terrain modules are the same as the 
entity modules but they must be identified as terrain for the amHLAAdmin module. These 
modules make up the core of this implementation. Each component is described in detail 
in the following sections. 

1. HLA Administration Module (amHLAAdmin) 

The amHLAAdmin module manages HLA RTI communications. Bamboo function 
calls, the execution window, and entities in the environment. All modules designed for the 
implementation depend on the amHLAAdmin module. Therefore, Bamboo ensures it 
loads before any entity or terrain module. Similarly, the amHLAAdmin module depends 
on various modules being loaded before it. Figure 3 shows the module dependency tree 
for a typical execution. Notice that amEntity and amTerrain depend on amHLAAdmin, 
and that amHLAAdmin depends on Visual, Keyboard, and amPageModule. 
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Bamboo 




amHLAAdmin 



amEntity amTerrain 



Figure 3: Implementation Module Dependency View 

Since the amHLAAdmin module must communicate with the RTI and 
entity/terrain modules, the API and pure virtual class provide the interface to accomplish 
this communication. Essentially, the amHLAAdmin module instantiates the Admin class 
object. Through static functions, the Admin class provides the API for entity/terrain 
modules to communicate with the RTI and manage instances of their entities. Each 
entity/terrain class must inherit from amObject. This object defines the interface for the 
Admin object to communicate with entity/terrain modules. 

Figure 4 shows the object model used by this implementation. This figure 
illustrates the relationship between the Admin object and the entity modules. It also shows 
how the pure virtual class amObject is used to ensure that each federate transmits and 
receives all information pertinent to the federation. An entity update coming from the 
network begins in the RTI ambassador receive buffer. 
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Figure 4: Object Interface 

Next, the RTI ambassador calls the AdminFederateAmbassador-::reflectAttributeValues() 
function in the federate ambassador). The federate ambassador is the RTI ambassador’s 
interface into the federate. This function simply calls the Admin object function to pass 
the AttributeHandleValuePair to the appropriate entity. 



Called by the RTI Ambassador to pass 

the AttributeHandleValuePairSet tO a Specific entity 

void Admin Fe derat eAmbass a dor : : ref lectAttributeValues 

( RTI : :ObjectID theObject, 

const RTI: : AttributeHandleValuePairSet& theAttributes, 

RTI: : FederationTime theTime, 

const RTI :: User SuppliedTag theTag, 

RTI: :EventRetractionHandIe theHandle ) 

throw (RTI : -.ObjectNotKnown, 

RTI : : AttributeNotKnown, 

RTI: : InvalidFederationTime, 

RTI: : FederatelnternalError) 

{ 

Admin: .-receiveUpdate ( theObject, theAttributes, theTime, theTag, theHandle) ; 

>// end reflectAttributeValues 

object id is the ID number for the specific entity 
The usersuppi iedTag specifies the module name. 

The other parameters are not used in this implementation. 



Figure 5: Federate Ambassador Code Fragment 
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The federate ambassador calls the Admin: :receiveUpdate() function in the Admin 
object (Figure 6). This function locates the entity object, an amObject type, in the object 
list. If the object exists, it is updated. If it docs not exist, the Admin object checks to see 
if the module is loaded. If the module is loaded, then another object representing that 
entity is instantiated. If the module is not loaded, it is loaded and an object representing 
the entity is instantiated. 



Called by the Federate Ambassador to pass 

the AttributeHandleValuePairSet to a specific entity 

managed by the Admin object 



void Admin: : receiveUpdate ( RTI : :Objec tID theObject, 

const RTI : : AttributeHandleValuePairSet* theAttributes, 
RTI : : FederationTime theTime. 

const RTI :: User SuppliedTag theTag, 

RTI :: Even tRetractionHandle theHandle ) 



( 




// find the correct object 



tmp->receiveUpdates (theObject, theAttributes, theTime, theTag) ; 
else { // add module if necessary or add simEntity 

if ( Admin : : moduleLoaded ( theTag) ) ( // is module loaded 



Add entity of module already loaded 



cout << ‘adding new • << theTag << endl; 
Admin : : adds imEnt i ty ( theTag , t heOb j ec t ) ; 

) / / end i f 
else { 



Load module and add entity from module 



cout « 'Loading Module ' « theTag << endl; 
Admin: : loadModule (theTag) ; 

Admin: :addSimEntity(theTag, theObject) ; 

) ) ) 



Figure 6: Admin Object Code Fragment 



The Admin object iterates the list of entities and calls the 

EntityObject::receiveUpdates() function of the appropriate entity (Figure 7). This 

function is defined in the amObject pure virtual class. This function iterates the 
AttributeHandleValuePair and sets the appropriate state variables in the entity object. 
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Called by the Admin object to pass 
the AttributeHandleValuePairSet to the entity 

void Boid: : receiveUpdates ( RTI : : ObjectID oid, 

const RTI : : AttributeHandleValuePairSet& theAttributes, 

RTI : : FederationTime theTime, RTI ; : UserSuppliedTag theTag) 

( 

RTI : : AttributeHandle attrHandle; 
unsigned long valueLength; 

Iterate theAttributes and set the values in the entity object 

for ( unsigned int i = 0; i < theAttributes. size {) ; i++ ) { 
attrHandle = theAttributes . getHandle ( i ); 
if ( attrHandle == Admin :: get Posit ionAttrHandle ( } ){ 
npsVec3f tup; 

theAttributes . getValue ( i, (char * ) &tmp, valueLength ); 
setPosition( tmp) ; 

)//end if 

else if ( attrHandle == Admin: :getOrientationAttrHandle ( } ) { 
npsQuatemion tmp; 

theAttributes. getValue ( i, (char* ) &tmp, valueLength ); 
setOrientation( tnp) ; 

}// end else if 

else if ( attrHandle == Admin: : get Ve loci tyAttrHandle ( ) ) { 
npsVec3f tmp; 

theAttributes . getValue ( i, (char * ) & tinp, valueLength ); 
setVelocity ( txrp) ; 

) ) ) 



Figure 7: Entity Object Code Fragment 

The Admin object is the portion of the amHLAAdmin module that implements the 
Admin API. This API is fully described in Appendix A: Implementation Tutorial. Users 
apply the Admin API to ensure their modules are managed as part of the HLA federation 
and the entities they represent are properly registered and updated by the RTI. Proper use 
of the API insures that the federation will comply with HLA Rules. 

The amHLAAdmin module loads and unloads modules in two ways: either 
automatically at the request of the system or explicitly at the request of the user. The 
Admin class defines certain API functions that load and unload modules at the request of a 
module or the system. Finally, the amHLAAdmin module loads user requested modules 
using a separate module called the amPageModule on which it depends. This module 
loads automatically when the amHLAAdmin module loads. The amPageModule executes 
the Bamboo calls that load and unload user requested modules. It installs two keyboard 
events that the implementer uses to arbitrarily load and unload modules. 

The amHLAAdmin module manages all of the simulation entities. Functionality 
related to this task are the HLA object management tasks like registering and deleting 
objects and ensuring state updates transmit to the correct entity. The amObject class, that 
all objects inherit from, allows the amHLAAdmin module to iterate its list of simulation 
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entities and update each object based on its ObjectID, an identification number provided 
by the RTI. 

Each module’s capability means nothing unless the executable is extended to 
include the new module. Figure 8 illustrates the execution tree used in this 
implementation. The amHLAAdmin module created the symbols in bold outline when the 
module loaded. A1 is a callback attached to the main callback handler created by the 
Bamboo core. A1 “ticks” the RTI to provide CPU time to the RTI ambassador and the 
federate ambassador. This callback drives the federate by processing all updates and 
providing them to the correct simulation entity. A2 is a callback attached to the draw 
callback handler of the Visual module. This callback calls the display function of all 
simulation objects using a call to a virtual function defined in amObject that all simulation 
entities must implement. Finally AK is the callback representing all keyboard events that 
are processed by the amHLAAdmin module. 




Figure 8: Execution Callback Tree 
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2 . 



Simulation Entities (amEntity/amTerrain) 



As the VE executes, if an entity is updated that is not currently represented on the 
local machine, the RTI initiates the discovery process. The UserSuppliedTag, a character 
string that is transmitted with each update handle value pair, represents the module name. 
The handle value pair is the HLA method of creating a byte array for transmission on the 
network. If this module is already loaded, then another object from this module is 
instantiated. If the module does not exist, then Bamboo loads it and instantiates an object 
that represents the newly discovered entity. 

Each simulation entity is a Bamboo module. Each module has two major 
components: the object’s polygonal representation and its general behavior. Therefore, 
when a module loads as a result of a remote object update, the user collects all the 
controls of that module. Then Bamboo plugs the module into the local event loop so local 
processing can compute entity appearance and behavior. Figure 4 shows the entity 
module loaded and inserted in the executable with two sets of callbacks. B 1 is the preapp 
callback that gives the user the ability to control the object with keyboard input. BK is the 
callback for all the keyboard inputs defined by the module. 

Because this system passes behaviors along with polygonal representation, there is 
an opportunity to reduce network traffic by reducing the details of entity behavior that 
previous systems transmitted via the network. This occurs because each entity computes 
its behavior locally not from a remote location. For instance, each entity provides collision 
event behavior locally without the need for multiple interactions transmitted across the 
network. Now the entity module notifies the federation only that a collision occurred, not 
resulting detailed state changes. Each entity computes those state changes locally as a 
result of the interaction. The result is a series of simulation actors whose behaviors and 
polygonal representations load dynamically at runtime. This allows simulation managers 
to easily experiment with the content of the environment by adding and subtracting 
functionality at runtime. The tendency is to think that this applies only to the graphically 
represented entities but it could mean that data loggers or analysis modules dynamically 
load and unload to collect and analyze simulation data. Bamboo provides an 
unprecedented method of adding functionality to an executing networked virtual 
environment. 



3. Graphics Rendering 

Bamboo’s Visual module renders the graphical objects in the scene. The 
amHLAAdmin module and the entity modules update the object's position and orientation. 
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Each entity module registers callbacks with the Visual module to ensure accurate 
rendering of the simulation entity. These callbacks call the appropriate functions when the 
system needs to render the graphical representation of each entity. See Figure 4 for the 
callback tree representing this implementation. 

B. FEDERATION OBJECT MODEL/SIMULATION OBJECT MODEL 

This implementation has a simple FOM. Table 4 displays the FOM tables for the 
implementation. The FOM and SOM are the same for this implementation because each 
federate is based on the amHLAAdmin Module common for all federates. The FOM 
defines the Entity State Object and its attributes that define the state of the object. The 
Entity State Object defines the attributes that will be communicated to the network. Do 
not confuse this object with the software objects defined in the implementation. Those 
C++ objects may define more variables that define their state but are not communicated to 
the network. The FOM also defines a very simple interaction called Collision. Its only 
parameter is the ObjectID number assigned to the entity that has been collided with. The 
purpose of this interaction is to communicate to the federation the ObjectID of the entity 
that was damaged. Each federate then updates the state of that entity. 



Object Clew Structure Teble 
Entity State (PS) 



Object Interaction Table 




Initiating Object 


Receiving Object 




Interaction 


Affected 


Affected 


hteraction 


krut 


Structure 


Class Attributes 


Class Attributes 


Parameters 


Sense 

React 


Collision 


EntityStata None 


Entity State Damage 


Entity ID 


IR 



Attribute P»f«m>t«r Definition Tebie 



Object/lnteractio 

n 


Attribute 

Perimeter D* t» type 


Card- 
inal It Reao- Accuracy Update Update 

y Unite lution Accuracy Condition Type Condition 


Updataebi 
T re rode re W a 

a Reflect* bl 

Acceptable e 




Position any 


1 


perfect 


^always 


Periodic = 


TA_ 


.„.;ur j 




Orientation any 


1 


j perfect 


always 


Periodic j 


TA 


:UR 


EntityState 


Velocity any 


1 


perfect 


always 


Periodic ^ 


TA 


UR 




Ammunition any 


i: 


perfect 


always 


Periodc 


TA 


UR 




Damage any 


V 


perfect 


always 


Periodic 


TA 


UR 




unsigned 














Collision 


EntitylD long 


i 


perfect 


always 


N'A N/A 


N/A 


N/A 



Table 4: Implementation FOM Tables 
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c. 



IMPLEMENTATION CONCLUSION 



Recall the goal is a dynamically extensible, flexible, consistent, and specific NVE. 
Dynamic extensibility is accomplished by using Bamboo to load and unload modules. The 
NVE is consistent because the amHLAAdmin module ensures all entity and terrain 
modules required by the designers be loaded when required. Each module is specific 
because the programmer is only concerned with one module representing a particular 
entity. That programmer no longer has to concern himself with the representations and 
behaviors of the other entities in the environment. Finally, all of this adds up to flexible 
environment that can be changed during runtime to the state required by the simulation 
managers. 

The preceding sections provide the overview of how the implementation 
accomplishes the goal of providing a dynamically extensible, flexible, specific and 
consistent NVE. Appendix A provides a detailed implementation tutorial that guides a 
user through the details required to implement an amEntity module. Appendix B provides 
the code examples that accompany the implementation tutorial. Together these two 
documents walk a user through the correct use of the HLA RTI, Bamboo and the 
amHLAAdmin module. 
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V. RESULTS AND LIMITATIONS 



A. PERFORMANCE RESULTS 

Two measures of performance were used to judge the merits of this 
implementation: frame rate per second and average time to clear the event buffer. Frame 
rate per second describes how the implementation impacts the graphics subsystem. Falling 
below ten frames per second severely hampers virtual environment realism. Time to clear 
buffers shows the impact of increasing numbers of entities on the system’s ability to 
update each one. Each measure was sampled with different communication reliability 
parameters, specific numbers of entities, and federates participating in the environment. 

1. Test Description 

The system used to evaluate the implementation is a Windows NT 4.0 LAN, with a 
166 MHz Pentium MMX CPU and 32 Megabytes of RAM. Each system connects to the 
100 Mbps LAN with a 3Com 10/100 Mbps network interface card through a 100 Mbps 
hub. The graphics subsystem on these systems is not accelerated. All graphics are 
computed on the system processor. There was a single federate per system Each 
federate computed and transmitted position, orientation, and velocity data every fifth 
frame. 




Figure 9: HLA Message Transport Types 
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There are two communication reliability settings defined by the HLA IF Spec: 
FED_REL1ABLE and RED_BEST_EFFORT. FED_RELIABLE uses the federation 
execution to ensure that each message of this type is delivered to each federate in the 
federation. This adds a significant number of messages to the network since 
acknowledgements are required to confirm delivery of each message. 
FED_BEST_EFFORT reduces message traffic compared to FED_RELIABLE because 
each federate transmits its messages to a multicast address where every other federate 
reads the messages. There is no requirement for acknowledgements, but there is a small 
chance that a message may be delivered improperly or not at all. Figure 9shows 
graphically the differences between FED_RELIABLE and FED_BEST_EFFORT 
reliability settings. FED_RELIABLE transport creates a bottleneck because the federation 
execution process acts as a server ensuring that all federates receive each update. The 
FED_RELIABLE transport type only allowed two federates in the federation before the 
federation execution was bottlenecked, so no further measurements were taken. Two 
federates does not make a very interesting virtual world. 

2. Frame Rate Results 

Figure 10 shows the frame rate results for a federate using the 
FED_BEST_EFFORT transport protocol. Notice that the frame falls as the number of 
entities in the federation increases. This is to be expected. Each new federate brings 44 
more polygons to the virtual world. 
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Figure 10: Performance Results 

3. RTI Event Buffer Read Results 

Figure 10 shows the time to clear buffer results. The time to clear buffer is the 
time required to process all events in the RTI event queue. In this implementation all 
events are attribute updates. This test shows the average time it took to clear the event 
buffer. Recall that the reliable transport type was only able to accommodate two federates 
with a total of 22 entities in the federation, while the best effort transport type 
accommodated more than three times that with 7 federates and 77 entities. Notice that the 
average time to clear the buffer increases with the number of entities in the federation. 
This could limit scalability, but recall the limited power of the test systems and that the 
entity module in the test does not implement dead reckoning. Dead reckoning could 
reduce the number of entity updates thus improving the time to clear the buffer. 

B. LIMITATIONS 

There are two major limitations in this implementation. The RTI limits the 
implementation due to its static nature. The design of the amHLAAdmin module is 
limited because it lacks a method of extending the executable by providing a separate 
thread to handle entity updates. 
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1 . 



HLA/RTI Generalization 



This implementation is generalized except for the HLA/RTI functionality. The 
RTI limits the functionality in two ways. First, the RTFs use of text files and environment 
variables limit the flexibility of this implementation. An API interface that set the RTFs 
state would significantly increase the flexibility of the system. Implementation of the HLA 
functionality requires that RTI be installed on every machine it is used on. It would be 
much more flexible if the RTI could be instantiated anytime and its state set with API 
function calls. This would allow the RTI to be part of the amHLAAdmin module and 
could be loaded in one step without having to actually install the RTI so that the static text 
files and environment variables are defined. Second, the FOM is predefined and parsed by 
the RTI at runtime. If there was an API interface to change the FOM during runtime, the 
federation could extend its capability without requiring that the federation execution be 
restarted. 



2. HLA Memory Footprint 

Each federation has three processes that must exist in order for the federation to 
operate: the RTI executive process, the federation executive, and at least one federate. 
The RTI executive process requires approximately 2.5 MB of RAM in order to run, while 
the federation executive requires 2.5 MB. Each federate’s memory requirements will 
vary, but the local RTI component, or RTI ambassador requires 12 MB. This is a total of 
17 MB required on one system. This is a significant amount of memory that must be 
considered when designing systems portable to desktop systems. 

3. amHLAAdmin Module Limitations 

The amHLAAdmin module does not provide a method for extending the 
executable. If this module provided a set of callbacks similar to the visual module’s app, 
cull, draw system, the implementation could better control the sending and receiving of 
information through the RTI. For example, a separate thread could be started that 
continuously “ticks” the RTI, thus keeping its receive buffers clear. Additionally, a 
generalized system that allows each module to register callbacks on an update loop would 
provide a more efficient method of updating entity state. These improvements were not 
made because the significance of the processing time required to update entity state was 
not discovered until the final performance tests were run. Future improvements to the 
system will require a better method of managing processor time for the RTI to update 
entity state. 
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VI. CONCLUSIONS 



A. CONCLUSION 

The implementation meets the requirements set out in the introduction concerning 
the improvements NVEs require. The requirements are the virtual environment must be 
dynamically extensible, flexible, specific, and consistent. This implementation is 
dynamically extensible. Bamboo does an excellent job of providing this capability by 
implementing the ability to dynamically extend the executable and providing a system that 
defines module dependency. The ability to load and unload modules on the command of 
the user or the system at any time during execution adds flexibility to the NVE. This 
means simulation designers can rapidly prototype simulation executions in real time and 
effectively design and implement the virtual environment. This demonstration verifies that 
simulation designers can be more specific. In other words, programmers just need to 
implement their module. They no longer need to represent the other entities that will exist 
in the NVE or approximate their behavior. An entity module that can be loaded as the 
situation changes and unloaded when no longer needed represents these remote entities. 
Finally, this system ensures that all simulations operating in the NVE are consistent with 
each other. The problem of different terrain models at each simulation site is solved 
because all sites receive the terrain module from the same location and execute it in the 
same manner. This same logic applies to the entity modules. 

B. FUTURE WORK 

The following lists future projects that could improve real time virtual 
environments. 



1. Network Bandwidth and Latency of the RTL 

It is very difficult to quantify the effects the RTI has on the network. We do not 
know the methods used to keep the distributed local RTI components updated. What is 
the time management method employed by the RTI? How are the receive buffers filled 
and emptied? What is the most efficient method of clearing the buffers? The results 
indicate that more information is required to increase the numbers of entities modeled in a 
real time virtual environment. 
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2. Methods for Reducing Network Traffic Required to Maintain 
Consistent Entity State. 

This work refers to ways to improve the RTI for real-time simulations. Area of 
interest management is a method of accomplishing this goal. The new version of the RTI, 
version 1.3-3, has implemented its own area of interest management system call Data 
Distribution Management (DDM). Future work could entail implementing support for 
DDM into this implementation. 



3. Improvements to the Current Implementation 

There are several ways to improve this implementation. First, the amHLAAdmin 
module could implement a series of callback handlers that accomplish the entity updates 
and interactions required by the system. This improvement would make the 
implementation more general by removing the requirement for the amObject pure virtual 
class interface. Next, multi-thread the implementation to provide specific amounts of 
processing time to the RTI and visual module. Finally, implement a system that ensures 
that locally computed objects are updated first. Currently, all entities are in the same list. 
Locally computed objects should have a separate list so they may be updated at a greater 
rate. 



32 



APPENDIX A: IMPLEMENTATION TUTORIAL 



A. INTRODUCTION 

This tutorial describes how to implement a module that will operate using the 
HLAAdmin implementation. It has three sections: Bamboo module implementation, HLA 
Implementation, and Demo. The Bamboo module implementation section describes how 
to build a module for use with the Bamboo virtual environment toolkit. The HLA 
implementation section outlines the HLA concepts that the user must understand to 
implement a module for the HLAAdmin implementation. Finally, the Demo section 
describes how to run the existing implementation. Taking each section in turn will ensure 
the user of an overall understanding of the HLAAdmin implementation. 

The system requirements for this implementation are, Windows NT 4.0, Visual 
C++ 5.0, RTI 1.0-3 and rktools. Visual C++ is the compiler used in the examples and 
rktools provides the functionality needed to use makefiles that are very similar to UNIX 
makefiles. All the RTI functionality described in this tutorial is explained in detail in the 
RTI Programmers Guide, see the bibliography in the main section of the thesis. 

B. BAMBOO MODULE IMPLEMENTATION 

The easiest way to grasp how to implement a Bamboo module is to use one as an 
example. I will use the amBoid module, available in the code appendix, as the example 
module. Bamboo modules are made up of a minimum of four files: module. h, module.c, 
amBoid.h, amBoid.c. (The amBoid files are examples; any name can be there.) Each 
module is identified to the Bamboo kernel by six global functions defined in the module.c 
file: getModuleName(), getModuleVersion(), getModuleDate(), getModuleText(), 
initModule() and exitModule(). As a module is loaded. Bamboo creates a bbModule 
object that holds pointers to these functions. 

When the module is loaded, the bbModule object executes the initModule() 
function. The initModule() function does the work required to add the module to the 
executable and instantiate any object required by the module. The exitModule() function 
removes the structures used to integrate the module into the executable and deallocates 



33 



the memory associated with any objects created for use by the module being deleted. 
Notice in the example module. c that the definition for the initModule() function makes one 
call to the initamBoid() function in amBoid.c, and the exitModule function makes one call 
to the exitamBoidO function in amBoid.c. 

The initamBoid() function does the functions described above. This function is run 
only once immediatley after the module is loaded into memory. First, it instantiates a Boid 
object for use by the module. Then it calls the initKeyboardFunc() to add callbacks for 
keyboard events. This is one way to add the module into the program execution. The 
other method is to add callbacks that will include the module’s functionality into the 
executable. This module is added to the executable by adding callbacks to the Visual 
module. The initVisualModule() function adds a callback to the preapp callback handler. 
The callback is associated with the preAppFunc() defined in amBoid.c. This function 
defines the keyboard controls and behavior for the Boid object created in the loadBoid() 
function. After this function is executed, the module executes as part of the Bamboo.exe 
executable until a command to unload the module. 

On the command to unload a module, the bbModule object calls the exitModule() 
function defined in the module.c file. This function in turn calls the exitamBoid() function. 
The exitamBoidO does the housekeeping required to remove from memory all structures 
like callbacks or objects related to the module. In this case, the exitamBoidO function first 
removes the event responses from the keyboard. Notice that these commands are in the 
reverse order of the commands that were used to create the keyboard events. Next the 
preapp callback is removed. Finally, all objects associated with this module are deleted 
from memory. 

The last Bamboo feature that will be discussed deals with module dependency. 
Bamboo extends the plug-in metaphor by implementing a system that allows modules to 
depend on other modules for execution. In this example, the amBoid module depends on 
the npsVisualModule, the bbKeyboardModule and the amHLAAdmin module. The 
module.txt file defines these dependencies. Bamboo ensures that all dependent modules 
are loaded first before the module that needs them is loaded. 
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This concludes the Bamboo section. It is not complicated to load and unload a 
Bamboo module. The user is required only to define the six functions in the module. c file. 
Understand that Bamboo’s greatest strength is its convention that defines generalized 
methods to load and unload modules while providing a system that ensures module 
dependencies are enforced. 

C. HLA IMPLEMENTATION SECTION 

HLA is implemented mainly in the arnHLAAdmin module. Entity modules just 
make an Admin API call to pass or receive information to the RTI. There is one exception 
to this that I will address later in this section. The Admin API wraps ups all RTI 
ambassador functions. When the arnHLAAdmin module loads, it instantiates a single 
object of type Admin. The entire API is static functions defined in the Admin class. 

The Admin class uses the following RTI functionality (* is a Federate Ambassador 
function): 

Federation Management 

CreateFederationExecution 
JoinFederationExecution 
ResignFederationExecution 
DestroyFederationExecution 
Declaration Management 
PublishObjectclass 
PublishlnteractionClass 
SubscribeObjectClassAttributes 
SubscribelnteractionClass 
Object Management 
RequestID 
RegisterObject 
UpdateAttributeV alues 
Disco verObject* 

Reflect AttributeValues* 

Sendlnteraction 

Receivelnteraction* 

DeleteObject 

RemoveObject* 

RTI Services 
Tick 
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The RTI has other functions that do not apply to this implementation like time 
management and ownership management. If this functionality is required, the Admin 
object can be extended. Refer to the Admin.c file in the code appendix for the following 
functions. Notice the Admin class constructor is protected. There can be only one 
instance of the Admin class active so a singleton is implemented called getlnstancef) that 
creates the object the first time it is called and returns the pointer to the object every time 
it is called. The Admin constructor instantiates the RTI ambassador (rtiAmb) and the 
Federate ambassador (fedAmb) objects. The rtiAmb is the predefined object that contains 
all the functionality that implements the IF Spec. The fedAmb is a pure virtual class that 
defines the interface between the RTI and the implementation. Each rtiAmb call results in 
a return value from the RTI or, in the case of updates, a call to a fedAmb function. Let us 
discuss how the implementation uses each of the above RTI services and discuss the code 
that implements the service. 

1. Federation Management 

The Admin constructor shown in Admin.c. makes calls to 
Admin: :createFederationExecution() and Admin: :joinFederation(). The 
createFederationExecution() function calls Admin::rtiAmb- 

>createFederationExecution(fedExecName) and passes it a char* that defines the name of 
the Federation execution. If the federation already exists, the rtiAmb throws a federation 
already exists exception. If the federation is new, then a fedex process is spawned by the 
RTI. The Admin: :rtiAmb->joinFederationExecution(federateName, fedExecName, 
fedAmb) passes it the name of the federate, the federation execution name and a reference 
to the fedAmb object. The name of the federate is name mangled by the RTI so it does 
not have to be unique and the fedExecName must be the same as was used in the 
createFederationExecution() function. The fedAmb reference is a pointer to the fedAmb 
created in the Admin constructor. The loop is used to give to the federate multiple tries to 
join the federation because the federation execution may require more time to configure 
itself before it is able to return the federate ID. The federatelD is a unique number 
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assigned by the fedex that identifies your federate. It is not required anywhere but may be 
required by the user. 

The Admin: :resignFederate() function handles the resign federate and destroy 
federate management functions. This function first calls Admin: :rtiAmb- 
>resignFederation() and passes an enumeration that defines the clean up the user wants 
done prior to federate resignation. The implementation uses 
DELETE_OBJECTS_AND_RELEASE_ATTRIBUTES. This value results in 
removeObject() calls to the fedAmb for all locally updated entities and releases the 
attributes on any objects that must transfer attribute ownership because the federate is 
resigning. The final call in this function is to the Admin::rtiAmb->destroyFederation(). 
This function destroys the federation if there are no other federates operating, otherwise 
an exception is thrown and the federation continues. 

2. Declaration Management 

Declaration Management identifies to the rtiAmb all the objects/interactions and 
attributes/parameters that the federate is interested in. After the federate is joined, the 
user must get from the rtiAmb the enumerated values for the objects/interactions and 
attributes/parameters computed when the FOM was parsed. The Admin::Init() function 
uses RTI support functions that use the information from the FOM to provide these 
enumerated values for the different objects/interactions and attributes/parameters. Notice 
the Init() function uses specific functions that provide the enumerated values for the 
different Objects (getObjectClassHandlefchar *)) and Attributes 

(getAttributeHandle(ObjectTypeEnum,char *)) that will be used by the federate. The char 
* parameter must match exactly with the strings used to describe the Objects and 
Attributes in the FOM. 

After the enumerated values are saved by the user using the Init() function, the 
user calls the Admin: :PublishAndSubscribe() function. This function makes RTI calls that 
tell the rtiAmb which Objects/Interactions and Attributes/Parameters the federate will 
publish and subscribe. The mechanics of this operation begin with the user building an 
RTI::AtrributeHandleSet. This data structure holds the attribute enumerations for a 
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specific object. The first part of the PublishAndSubscribe() function builds the 
RTI::AtrributeHandleSet. First the set is declared. Then space is allocated for five 
attributes using the create method of the RTI::HandleSetFactory object. Finally, all 
attributes that the federate wants are added to the set using the add(AttributeHandle) 
method and passed the enumeration for the specific attribute to be added. After all the 
attributes are added to the HandleSet the Admin: :ms_rtiAmb- 
>subscribeObjectClassAttribute( ClassHandle, *HandleSetFactory ) and 
Admin: :ms_rtiAmb->publishObjectClass(ClassHandle, *HandleSetFactory) are called to 
tell the rtiAmb those objects that will be published and subscribed. The last functions are 
for subscribing and publishing Interactions. Notice that these functions do not require a 
HandleSetFactory. When a federate subscribes or publishes an interaction, it accepts 
responsibility for all the parameters of that interaction, hence there is no need to tell the 
rtiAmb which parameters it is responsible for. 

The above functions accomplish all the tasks required to publish and subscribe to 
objects/interactions and attributes/parameters. These are required tasks that all federates 
must accomplish in order to participate in the federation. 

3. Object Management 

Object management services provide the functionality to identify entities to the 
RTI, discover them on remote federates, and update their attributes during the federation 
execution. The RTI requires that all entities are associated with an Object defined in the 
FOM. All entities must possess a unique ID number provided by the RTI. This number 
identifies the entity on all federates in the federation and ensures updates and interactions 
are processed on the correct entity. 

The first task when adding an entity to the federation is getting its Objectld from 
the rtiAmb then registering that ID with the rtiAmb. The Admin: :registerObject() function 
accomplishes these tasks. First the Admin::ms_rtiAmb->requestID(RTI::ObjectIDCount, 
RTI:: Objectld, RTI::ObjectId ) function provides the ObjectID numbers. Then the 
Admin: :ms_rtiAmb->registerObject( RTI::ClassHandle, RTI::ObjectId ) function registers 
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the entity with the rtiAmb and associates it with a Object that was previously published or 
subcribed. 

After the object is registered with the rtiAmb, the entity will be updated and its 
attributes reflected on all participating federates. This task requires that the entity be 
discovered by each federate in the federation. Discovery requires that the entity be 
updated at least once. On the first update, the rtiAmb calls the 

FederateAmbassador::discoverObject() function. This function then ensures the module is 
loaded that represents this object. After the module is loaded an entity is instanced and its 
state is updated with the attributes passed by the rtiAmb. Refer to the 
AdminFederateAmbassador.c file for the discoverObject() function. After the object is 
discovered, all updates come to it through the 

FederateAmbassador: :reflect Attribute Valuesf) function. We will look at how the 
attributes are updated first. Then we will look at the discoverObjectf) function is detail. 

Entities are updated using the rtiAmb->updateAttributeValues() function. The 
implementation calls this function in the Admin: :sendEntityUpdate(RTI::ObjectID , 
RTI::AttributeHandleValuePairSet& , const RTI::UserSuppliedTag ). Each entity must 
implement the virtual function sendUpdatesQ defined in amObject. This function 
produces a RTI::HandleValuePairSet then calls the Admin: :sendEntityUpdates() function. 
Refer to boid.c in the code appendix for listings of entity functions. Boid::sendUpdates() 
first creates a HandleValuePairSet with the attributes in it that it wants to update. Then it 
calls Admin: :sendEntityUpdate() and passes it the Objectld of the entity to be updated, its 
HandleValuePairSet and the UserSuppliedTag which identifies the module that the entity 
is modeled by. Admin::sendEntityUpdates() then calls the Admin: :rtiAmb-> 
update Attribute Values( Objectld, HandleValuePairSet, FederationTime, 

UserS uppliedTag( ). This command sends a packet out on the network containing the 
data specified. When a remote federate receives the data the rtiAmb calls the 
FederateAmbassador::discoverObject() function if the Objectld is not known to the 
federate or the FederateAmbassador::reflectAttributeValues() function if the entity already 
exists in that federate. 
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The AdminFederateAmbassador:: re fleet AttributeValuesQ function calls the 
Admin: :receiveUpdate() function. This function searches the list of entities and then calls 
the Boid::receiveUpdates() virtual function defined by the amObject class. The 
Boid::receiveUpdates() function decodes the Handle ValuePair using the getValue() 
method and updates the appropriate state variable. It then deletes the HandleValuePair. 

If the entity is not known, the rtiAmb calls the FederateAmbassador 
"disco verObject() function. This function ensures the appropriate module is loaded then 
calls Admin: :addSimEntity() to ensure the entity is added to the list of entities displayed by 
the federate. On the next update, the entity’s state is updated using the previously 
described process. 

The process for interactions is very similar. An entity generates an interaction and 
uses its Boid::sendInteraction() function. This function calls the Admin: rrtiAmb- 
>sendInteraction() function. This provides more flexibility to the federate. The 
interaction is received on the remote federates and the rtiAmb calls 
FederateAmbassador: :receiveInteraction() function. This function then calls the 
Admin: :receiveInteraction() function which finds the affected entity and calls the 
Boid::receiveInteraction() function. In this function the parameters changed by the 
interaction are modified and the ParameterHandleValueSet is deleted. 

This implementation also has the ability to delete entities from the federation. This 
is accomplished using the RTI functions deleteObject and removeObject. When an entity 
is identified for deletion, the entity is deleted locally then the rtiAmb is notified of the 
deletion through the deleteObject function. This causes a network message that results in 
the remote federate rtiAmbs calling the FederateAmbassador: :removeObject() function. 
The details follow for this implementation. First an entity identified for deletion and its 
geometry are deleted from the local environment. Then the Admin::removeAmObject() 
function is called. This function removes the entity from the object list and calls 
Admin: :rtiAmb->deleteObject() which results in a call to the 
FederateAmbassador::removeObject() function. This function then calls the 
Admin::removeAmObject() on the remote federate. This process notifies the federation of 
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the entities to be deleted and makes the calls necessary to remove the entity from the 
object lists in all federates. 

4. RTI Services 

The final topic concerns how the rtiAmb is allocated processing time. The RTI is a 
single threaded application, so processing time is allocated through the use of the tick() 
command. This command causes the rtiAmb to accomplish tasks such as clearing buffers 
and executing callbacks based on the status of the federation. 

The tick() function has two forms. The form used in the implementation ticks the 
rtiAmb once for each call. The other form , tick(min,max), will tick the rtiAmb for a 
specific length of time. Both forms return a boolean value indicating if there are more 
events in the queue. This function must be run periodically in order for the federation to 
operate. Waiting too long to tick can result in overfull buffers that take an inordinate 
amount of time to clear thus reducing the overall speed of the federation. In this 
implementation the rtiAmb is ticked once per frame to provide the most updated 
information to each federate. 

D. DEMO INSTRUCTIONS 

❖ Start the RTI executive. 

❖ Open two command windows. 

❖ In both command windows, change directory to the bamboo directory. 

❖ Type bamboo arnHLAAdmin in both windows. 

> CTRL-E exits arnHLAAdmin ( mouse must be in the execution window ) 

> The federation execution (fedex) should have started in another window 

> There should be two light green windows ( move the top one to see the other ) 

❖ Now add modules to the federation. 

> Add the Arena Terrain. 

■ Type CTRL-L to load module. 

■ Enter the module name amArena. 

■ Type CTRL-T to promulgate the module to all federates. 

♦♦♦ Now populate the environment. 
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> Type CTRL-L to load module. 

> Enter the module name ainBoid. 

> Type B to create the Boid. 

■ Control the boid with the arrow keys. 

■ The A key makes it go forward. 

■ The S key makes it go backward. 

❖ Do the above in both windows. 

> Turn the boid that you can the other in both windows. 

> Collide one boid with the other. 

■ This produces an interaction. 

■ After 10 hits the boid is destroyed and should disappear. 

■ To add another boid type B again. 
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This is the t 



Iron the moduie ext file 



amHIiAAdmin Files 



Bambool Ob 
4 

npsVisualModule 

bbK^yboardModul** 

npsFlyingCamejaModule 

amRageModule 



| 



n 

tt EXECUTIVE SUMMARY 

// 

1 1 File Name: module. h 

II 

/ Author CPT Stewart Liles. Naval Postgraduate School 

// Description; This file defines the global functions required by 
//■ every dynamically- linked library. How these functions are 
implemented is arbitrary, but it is useful have RCS 
automate some of the work. 

September 1998. Masters Thesis 



•ifndef module 

•define module 



FUNCTION PROTOTYPE SPECIFICATIONS 



•lfdef cplusplus 

extern *C* { 

•endi f 

SIM_API const char 'getModuleName ( ) ; 
5IM_API float getModuleVers ion ( ) ; 
SIM_API const char 'getModuleDate () ; 
SIK_API const char 'getModuleText () ; 
SIK_API bool initModule () ; 

SIM_API bool exitModule ( ) ; 

•lfdef cplusplus 

) ; 

•endi f 

• endif II module 



II 

II EXECUTIVE SUMMARY 

// 

// File Name, modal e.c 

n 

II Author; CPT Stewart Liles. Naval Postgraduate School 

// 

// Description This file defines the global functions required by 
// every dynamically-linked library. How these functions are 

// implemented is arbitrary, but it is useful have RCS 

// automate some of the work. 

// 

// September 1998. Masters Thesis 

// 

// 

// INCLUDES AND EXTERN S 

// 

•include <stdlib.h> // atof 
•include 'module. h* 

•include 'amHLAAdmin. h* 

// 

// CODE 

// 

const char 'getModuleName [ > 

( 

return 'arnKLAAdmin* , 



float getModuleVers ion ( I 

{ 

return 1.0; 

} 

const char 'getModuleDate ( ] 

< 

return "1998/08/01 06:0S 48'. 

) 

const char 'getModuleText ( } 

{ 

return 'amHLAAdmin Module -- CNTL-E to exit'; 

) 

bool initModule [) 

{ 

initAdmin { ) ; 
return 1; 

} 

bool exitModule () 

( 

exitAdmin ( ) ; 
return 1; 
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EXECUTIVE SUMMARY 


EXECUTIVE SUMMARY 


File Name anHLAAdmin h 


File Name amHLAAdmm c 


Author CPT Stewart Liles Naval Postgraduate School 


Author CPT Stewart Liles Naval Postgraduate School 


Description Defines the module controls for the amHLAAdmm module 


Description Defines the module controls for the amHLAAdmir. modu.e 
This module manages the communication between ;»a»rat»5 and 


September 1998 Masters Thesis 


has daca structures avilaole za facilite collision detection 
and other tasks that require comparison w.th a.l other 
simulation entities 


•ifndet _amHi-AAdmin 
•define _amHLAAdmin 


>pt*:»er Mast-rs Thesis 


INCLUDES AND EXTERNS 


INCLUDES AND EXTERNS 


•include ‘admin. h* 


•include *Rti hh* 


FUNCTION PROTOTYPE SPECIFICATIONS 


• include ‘amHLAAdmm h‘ 
•include ‘bbKeyboard h* 

• include ‘bbEventResponse h* 
•include ‘bbCa llback h* 
•include ‘bbModule h* 


void lnitAdminl), 


•include 'admin h* 


void exitAdmm ( ) . 


•include ‘npsWindow h* 
•include ‘npsViewport h* 
•include ‘npsCamera h* 
•include ‘npsVisual h* 


// INLINED MEMBER FUNCTIONS 


•include ‘bbMouse h* 
•include ‘amObject h‘ 
•include ‘ace/OS h* 
•include <math.h> 


•endif II _bbHLAAdmxn 


•include <GL/gl h> 

•ifdef SGI 

•include ‘bbSGI h* 

•endi f 

CODE 

• Function Name lnitAdminl) 

Task Makes initial calls to make module a part of the executable 

Return Value void 

void ifiitAdmm ( ) ( 

void mitDisplayWindow ( j . 
void mitKeyboardModule;i, 
void createMamCallbackHandler ( ) , 

Admin : . getlnstance ( ) ; 


createMainCallbackHandler ( ) ; 
initKeyboardModule ( ) ; 
initDisplayWindowf ) • 


npsCamera ‘camera, 

npsViewport ‘viewport; 

npsVec3f position; 

bbCal lback ‘callback; 

bbCal IbackHandler ‘callbackHandler; 


)// end initAdmin 


//create the window for the simulation 
window = new npsWindow ! 370 . 370). 
wmdow->setName ( ‘Admin Window* } ; 


// Function Name exitAdmm <) 

/ t Task deletes callbacks etc to ensure the module is unloaded 

n gracefully 


viewport = new npsViewport ( 0 . Of . l.Of. O.Of. l.Ofl. 
viewport->setName ( ‘AdminViewporf ) . 

// camera to view the area 


/ / Return Value void 


camera - new npsCamera ( ) ; 
camera->setName ( * AdmmCamera* ) . 
camera -> set FarCl ip ( 200 . Of ) . 
posi tion . set ( 0 . 0 f . 3. Of, 10. Of); 


void exitAdmm U { 

bbCal lback* callback: 

bbEventResponse* eventResponse . 

bbCal IbackHandler * callbackHandler ; 


eamera->setPosition(position| , 

camera->setClearColor(0.66f . l.Of. 0.66f. l.Of). 
camera-»secAspectMode (npsCamera . :CALC — VERT) ; 
viewport -> setCamera (camera ! . 


Admin: :getMutex ( ) ->acquire f ) ; 

// delete keyboard callbacks 
// exit key 

eventResponse = bbEventResponse. f indObject ( *amHLAAdminER_Exif ) ; 
callback = bbCa 1 lback :: f indObject {* amHLAAdmm_Exi f J ; 
eventResponse->removeCallback (callback! , 
delete callback. 


window-s addViewport (viewport) ; 

II callback to change position of camera and update screen 
callback = npsVisual ; : drawCa llback () , 
callbackHandler = callback-xgetPreCallbackHandler { ! . 
callback i new bbCa 1 lback () , 
callback->setName f * amHLAAdmin_preDraw* ) , 
callback-*setFunc IpreDrawFunc ) . 


II resign federate 
Admin: resignFederate t ! ; 


callbackHandler->addCallbacki^st (callback) ; 


// delete Admin instance 

Admin* tmp = Admin : : gee Instance :: 

delete tmp; 


' t /mitDisplayWindow 


Admin : ■ getMutex ( ) ->release ( ) ; 


// Function Name preDrawFunc () 

II Task calls Admin display to update simulation entitles 


exit (0) ; 


// Return Value- void 


) 

// Function Name mitDisplayWindow i ) 

// Task inits main window for the federate. Bamboo currently only 

// allows on window open at time. This is the window for the 

// federate 

// Return Value' void 


void preDrawFunc t bbObject ‘object, bbData ‘data) ( 

Admin: getlnstance () ->display t ) : 

) / / end preDrawFunc 

// Function Name. createKainCal IbackHandler ( ) 

Task puts callback on the bamboo mam event loop. this is done 


void mitDisplayWindow ( ) { 


because RTI 1.0-3 requires that the RTI be ticked from the 
// same thread that instantiated it 


void preDrawFunc (bbObject ‘object, bbData ‘data). 


// Return Value void 



npsWindow 



■window; 



. :re.»- eMainCal IbackHandler 

J hlaTickRTI (bbvbject bbData ‘data 

bbCallback‘ callback. 

bbCal lbackHandler* callbackHandler 

-al lbar<Handl-r * bbCa 1 lback>(andl<*r findobjeet *ma. _a 1 lbaekHandler* 
ra I iba w k - n«*w bbCal lback ( I 
cal lback ->setName ‘rtiTick*). 
r.a 1 lbark->set Func I hlaTickRTI) 

•a 1 Ib.ackHandler - >addCallbackLa:; t (callback t . 

end cr'*aceMamCaiibackHand.ej 



Function Name mi tKeyboardMudule 

Tas< creates module keyboard callbacks 

Return Value void 



void initKeyboardModule v ( 

void exitFunc (bbObject ‘object. bbData ‘data), 
void hlaUpdate Bo id (bbObject ‘object. bbData ‘data), 
void hlaTickRTI (bbObject ‘object. bbData ‘data:, 
void hlaUpdateQbject (bbObject ‘object bbData ‘data! . 
void hlaUpdateC lass (bbObject ‘object. bbData ‘data . 

bbKeyboard ‘keyboard. 

bbOent Response • eventResponse , 

bbCal lback ‘callback. 

get the keyboard device 
keyboard = bbKeyboard get Instance n . 

set up exit key 
eventResponse - new 

bbEventResponse (bbKeyboard KEY_E | bbKeyboard CTRL_KASK 
bbKeyboard • DOWN_TRANS ) . 

eventResponse->setName ! *amHLAAdminER_Exit ‘ I , 
callback = new bbCa 1 lback I ) . 
cal lback->setName t ‘amHLAAdmin^Exit ‘ ) ; 
cal lback->setFune (exitFunc ) . 
eventResponse- >addCa 1 IbackLast (callback) ; 
keyboard- >addEventReSponse (eventResponse I . 

end mitKeyboardModule ( l 



Function Name exitFunc 

Task callbck function for cntrl-e that exits the federation and 
ensures all callbacks are cleaned up 
Return Value void 



void exitFunc bbObject object bbData ‘data 
int mouselnWindow 

bbModule ‘module. 

if (mouselnWindow! . ! 

module bbModule f lr.dObject ; ‘amHLAAdmvn* 
if I ’ modu 1 e j ( 

cout << "amHLAAdmir. is not currently loaded .gno: ing* «< endl . 
return. 
t//end if 

it I 'bbModule unload module))! 

cout << * Error unloading amHLAAdmin * << e n dl, 
cout *•< ' Fatal Error • aborting executable'* «< endl << endl. 
exit '0) . 
i ' 1 end if 
l /end if 

)/ exitFunc, 



Function Name. hlaTickRTI 

Task: callback func that makes the RTI calls that tick the rti 

this provides the cpu time for the rti to get its worx done 
Return Value void 



void hlaTickRTI (bbObject ‘object. bbData *data){ 

RTI : FederationTime tmpTime ( 1 0). 
while (Admin, get Instance f ) ->tickRTI () i . 

Admin : . get Instance ( ) ->update Federation (tmpTime ) . 
)// end hlaTickRTI () 



// Function Name: mouselnWindow 

// Task: ensures the mouse pointer is the window that you want to 

// update 

// Peturn Value integer that is interpreted for use as a bool 



int mouseinWindow( ) ( 

int flag = 0; 

npsWmdow ‘window. 

npsViewport ‘viewport. 

window = npsWmdow fmdOb ject ( ‘AdminWindow* ) , 

viewport = npsViewport :• findObj ect ( * AdminViewport ‘ J . 

float x.y. 

X = bbMouse getXIJ; 



y = bbMouse . getYO; 
bbScreen : : norma 1 1 * eVa 1 ( tx . ty ) ; 

if (viewport->getWmdow( ) -> isVal Inside (x. y) ) ( 
flag - 1; 

) 

return flag; 

)// end mouselnWindow!) 

// end amHLAAdmin . e 






// 

U EXECUTIVE SUMMARY 

// 

// File Name- admin. h 
II 

// Author: CPT Stewart Liles, Naval Postgraduate School 

II 

// Description' Definition of Admin class 

// This file defines the utility and external API functions 
// required to manage an amCompatible federate 

// 

II September 1998. Masters Thesis 





• include "Rti.hh* 

• include ‘AdmmFederateAmbassador . h" 
•include *npsVec3£.h‘ 

•include ‘npsGeometry . h* 

•include ‘bbKeyboard h‘ 

•include ‘amObject.h* 

• ifndef _admm 
•define _admm 



//defines 



•ifndef SIM_API 
•ifdef VISUALCPP 

•define SIM_API dec lspec (dllimpor t ) 

• else 

•define SIM_API 
•endi f 
•endl £ 



class SIM_API Admin 

( 

//member variables 
public : 

// Simulation Entity data memebers 

static vector<amObject*» ms^amObjectArray ; 

static unsigned int ms_NumberAmOb jects ; 

// Array of Dbjects used by modules 
static vector<amObject*> ms_ModuleArray ; 
static unsigned int ms_NumberModules ; 

It The Terrain Object pointer 
static amObject* ms_Terrain; 

// time management variables 

static RTI::Boolean ms_t imeAdvGrant ; 

static RTI FederationTime ms_grantTime . 
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RTI Ambassador pointer 
static RTI RTIambassador* ms_rtiAmb 

static RTI FederateHandle m federatelD 



' flag that signals whether interactions ar<> valid 
static RTI Boolean ms_:nteractionFlag. 

name of the Federation Execution 
static char* const m_Fed£xecName . 

f provides url to module locations 
static char* const tns_ModuleURL. 



private 

!, Static Member Data 

// Federate Ambassador Pointer 

static A dminFedera te Ambassador* ms.fedAmb. 



mutex . .ed : make Adm . " Thread Safe 

■st.: ACE_Recursive_Thread_Mutex adminMutex 

member functions 

puhl 1C 

' ' destructor 
virtual -Admin 

ensure; update of th* federation 
••’iid updaieFederationfRTI Federat lonTimeL newTime 

This is the Admin API portion 

singleton getter 
■ •tatic Admin • get Instance I ) . 

' -«nd data to RTI 

static void sendColl isionlnteraction ' RTI Federat i onTime theTime 
RTI Object ID oid . 

static void sendEnti tyUpdate i RTI • Obj^ecID theObject 

RTI AttnbuteHandleVa luePairSetu theAtt nbutes. 
const RTI UserSuppl iedTag theTagj . 



/ / RTTI dat 
Static RTI 
static RTI 
static RTI 
static RTI ■ 



i provided by the RTI during Inii 



ObjectClassHandle 
AttributeHandle 
At tribute Handle 
AttributeHandle 



ms_AdmmClassHandle . 
ms_ModuleURLAttrHandle . 
ms_ModuleVersionAttrHandle . 
ms_ModuleNameAttrHandle , 



static RTI 
static RTI ■ 
static RTI. 
static RTI 
static RTI 
static RTI . 



ObjectClassHandle 
AttributeHandle 
■ AttributeHandle 
AttributeHandle 
AttributeHandle 
. AttributeHandle 



ms_ESClassHandle 
ms_Posit lonAttrHandle. 
ms_Onentat lonAttrHandle, 
ms_VelocityAttrHandle. 
ms _ AmmunitionAttrHandle. 
ms_DamageAttrHandle, 



static RTI. : Int eract lonClassHandle 
static RTI ParameterHandle 



ms_CollisionInteractionHandle. 
ms_EntityIdHandle . 



II Names for querying RTTI values 



static 

static 

static 

static 

static 

static 

static 

static 



char* 

char* 

char’ 

char* 

char* 

char* 

char* 

char* 



const 

const 

const 

const 

const 

const 

const 

const 



ms_ESClassSt: . 
ms_PositionStr . 
ms_OnentationStr . 
ms_VelocityStr . 
ms_AmmunitionStr, 
ms_DamageStr; 

ms_CollisionInteractionStr ; 
ms_EntityIdStr ; 



>! constructor is private due to singleton 
Admin ( ) ; 



// singleton 
static Admin *this_. 



/ Receive data from RTI 

static void rece iveUpdate ( RTI ObjectID theObject. 

const RTI AttnbuteHandleValuePairSetfc theAt tributes . 

RTI FederationTime theTime. 

const RTI UserSuppl iedTag theTag. 

RTI : EventRetractionKandle theHandle t . 

static void receivelnteraction ( RTI InteractionClassHandle 
thelnteraction. 

const RTI ParaneterHandleValuePairSeti the Parameters . 

RTI FederationTime theTime. 
const RTI UserSuppl iedTag theTag. 

RTI: EventRetractionKandle theHandle). 

i Manage Sim Entity Pointers 
static void display!). 

static void addModuleFunct ion Pointer I amObject* i . 
static amObject* f indSimEnt 1 ty ! RTI . : Obj ectID objectld ). 

static amObject* f indSimEnt ity ( const char * modu leName , ; 

static RTI * • Object ID regi sterObject t) ; 

static amObject* addSimQit ity (const char* moduleName. RTI ObjectID! 
static amObject* checkEnti tyCollis ion (amObject * that), 
static void removeAmObj ect (RTI •. ObjectID oid) ; 

// Module Object Management 

static RTI . Boolean modul eLoaded (const char’ moduleName:; 
static void loadModule { const char* moduleName), 
static void unloadKodule (const char* moduleName). 
static amObject* findModule (const char* moduleName], 
static void removeModule (const char* moduleName). 

// RTI execution management 



static RTI . : Boolean tickRTIU; 

static RTI:. Boolean tickRTI (RTI : TickTime minTick, RTI : .TickTime maxTick); 

static void advanceTime (RTI .: FederationTime time); 

static void resignFederate ( ) , 

static void joinFederation( ) . 

static void setTimeManagement ( ) ; 

static void createFederationExecution ( ) ; 

static void Imt ! ) , 

static void PublishAndSubscnbe ( ) ; 

static ACE_Recursive_Thread_Mutex* getMutex!); 



// Accessor Methods 
// Static Accessor Methods 

static RTI : ObjectClassHandle getESClassHandle ( ) 

( return ms_ESClassHandle ; ); 

static RTI :. AttributeHandle getPosi t 1 onAttrHandle ( ) 

( return ms_PositionAttrHandle ; }; 
static RTI AttributeHandle getOnentationAttrHandle ( ) 

( return ms_OnentationAttrHandle; ); 
static RTI; AttributeHandle getVelocityAttrHandle ( ) 

( return ms_VelocityAttrHandle, ); 
static RTI : AttributeHandle getAmmunitionAttrHandleU 

( return ms_AmmunitionAttrHandle; ); 
static RTI :: AttributeHandle getDamageAttrHandle O 

( return ms_DamageAttrHandle . ); 

static RTI: .InteractionClassHandle getCol lisionlnteractionKandle ( ] 
(return ms_Col 1 is ion Int eract lonH an die , ) 

static RTI :: AttributeHandle getEntityldHandle ( } 

{ return ms.EntityldHandle, }; 



) ; // end Class Admin 
•endlf 



// * 

ft EJCECUTIVE SUMMARY 

// 

// File Name, admin. c 

// 

// Author. CPT Stewart Liles. Naval Postgraduate School 

// 

// Description: Method Definitions of Admin class 

// This file defines the utility and external API functions 

// required to manage an amCompatible federate 

// 

If September 1998. Masters Thesis 

// 



•include 
•include 
•include 
•include 
• include 
•include 
•include 
•include 
•include 



•RTI .hh* 

‘admin . h* 

* AdminFederateArabassador . h* 
•npsGeometry h* 

•bbKeyboard . h" 

•bbModule . h* 

’amObject . h‘ 

* ace /OS . h* 

•vector .h‘ 



// Static Variable initializations 

// singleton 

Admin * Admin . : this_ = 0; 

RTI :: RTIambassador* Admin : :ms_rtiAmb = NULL. 
AdmmFederateAmbassador* Admin: ms_£edAmb = NULL. 
RTI : : FederateHandle Admin: . m_federateID = 0, 
vector<amObject*> Admin: : ms_amObjectArray ; 
unsigned int Admin: . ms_NumberAmObjects = 0, 
vector<amObject*> Admin r : ms_ModuleArray . 

unsigned int Admin : ms_NumberModules = 0; 
amObject* Admin :: ms_Ter rain - NULL. 



//Time Management flags 

RTI : : Boolean Admin :: ms_timeAdvGrant = RTI : : RTI_FALSE ; 

RTI . . FederationTime Admin : . ms_grantTime (1.0); 

RTI : FederationTime Admin: : m_lastTime . 

RTI:: Boolean Admin : ms_InteractronFlag = RTI . RTI_FALSE; 
// RTTI data 
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RTI ■'bjeetN. lassHandle Adm. . 

RTI At tnbuteHandl* Admjr’ 

RTI Aur ibuceHandl* Admir. 

RTI Attr ibuteHandl- AJrnn 

RTI AttributeHandle Admin 

RTI Atir ibut*Handi<* Admir. 

RTI Inc^ractionClassHandl^ Admir. 

RTI Param^terHandle Adm.r. 



ms E- ' lassHandl- 
ms PcsitionAttrHan lie 
ms_uri'ntationAUrH«ndl' 0 
m.i_V»-iocityAttrHandl^ - 0. 
n5_Ammunit lonAttrHandle = 0, 
ms Damag^AttrHandle : 0. 

ms .Co I lision Interact lonHandi* 0 
ms EncityldHandle - 0 



Nam<*3 for 
char* const 
char* const 
char* const 
char* const 
ehas* const 
char* const 



querying RTTI values 

Admin ms E^ClassStr * Ent ltyStat* - , 

Admin ms_Positionf.tr - 'Position*. 

Admin ms. Tientat lonStr - *0r lent at ion* . 
Admin ms '•> 1 ;,c ityStr = "Velocity*. 

Admin ms Ammunit lonStr i ‘Ammunition*. 
Admin ms .Dama geStr - * Damage*. 



char* const 
char* const 



Admin ms_Col lisionlnteract lonStr - 'Collision*. 
Admin ms _Ent ityldStr * ‘EntitylD*. 



char* 



const 



Admin m_PedExecName - *HLA_Admin*. 



char* const 



Admin ms_ModuleURL - *URL not defined* . 



ACE_Recur sive_Thr ead_Mutex Admin ■ adminMut *x . 



Construction/ Destruc' 




Punction Name gee Instance i > 

Task singleton accessor function 
Return Value Admin* 



Admin* Admin . getlnstance I ) ( 

if ( ! this_i { 

this_ - new Adminl), 



return this_. 
)//end getlnstance ( ) 



try rtiAmb 

Admin ms_rt lAmb new RTT RTIambassador 
Admin ms_fedA»t - new AdminPederateAmbassador ■ . 

i //try rtiAmb 

catch (RTI ConcurrentAccessAt tempted! e 

( 

cerr << 'Instantiate rtiAmb and fedAmb* <* *ndl. 
cerr << we < < er.dl, 

catch (RTI' .Exception! e 

( 

cerr '< 'Instantiate rtiAmb and fedAmb* << *ndi. 
cerr << we << endl. 



createFederat lonExecucion ! 
joinFederat ion ( ) . 

end constructor 



// Function Name -Admin i 
// Task destructor 
/ Return Value none 



Admin . : -Admin I ) ( 
amObject* tmp; 

vector<amObject*> . iterator ptr, 
getMutex ( ) -^acquire I ) . 

//delete all elements of Object Array 
ptr = ms_amObjectArray . begin () ; 
while(ptr '= ms_amObjectArray . end M ) { 
tmp - (amObject* ) *ptr . 
if (tmp) { 

delete tmp, 

) / /end if 
ptr** . 



Function Name Admin () 
Task. constructor 
Return Value, none 



Admin- Admin () { 



ms_amOb j ect Array empty ( ) . 

//delete ms_ModuleArray 
ptr - ms_ModuleArray .begin ( ) . 
while (ptr != ms_ModuleArray end(}){ 
tmp = (amObject* ) *ptr; 
i f ( tmp ) { 

delete tmp; 

)//end if 



ptr** ; 

) 

ms_ModuleArray empty ( ) ; 

getMutex ( ) ->release ( I ; 

// delete ms_Terrain 
if (ms_Terram) delete ms_Terrain; 

// delete the ambassadors 
if (ms_rtiAmb) delete ms_rtiAmb, 
i f (»s_£edAmb) delete ms_£edAmb. 



// Function Name f indSimEnticy ( RTI . .ObjectID objectld ) 
Task find a simulation entity given its Object ID 
// Return Value amObject* 



amObject* Admin :•.£ indSimEntity ( RTI : -.ObjectID objectld )( 

amObject* amPtr = NULL; 
amObject* tmp = NULL; 

vector<amObject *> : : const_iterator ptr; 
getMutex I ] ->acqui re(| ; 

// iterate the vector ms_amOb jectArray 

for (ptr * ms..amObjectArray begin () ; ptr != ms_amOb jectArray end () ; 
ptr** ) ( 

tmp = (amObject*) ( *ptr) , 

if (tmp ww ( tmp->getEntityID( > == objectld) ) ( 
amPtr = tmp , 
break. 

)//end if 
)//end for 

getMutex ( ) ->release ( ) ; 

return amPtr; 

)// end f indSimEntity 



// * 

// Function Name f indSimEntity ( const char* moduieName ) 
// Task: find a simulation entity given its Module’s name 

// Return Value. amObject* 

// 

amObject* Admin f indSimEntity ( const char* moduieName |( 

amObject* amPtr = NULL; 
amObject* tmp s NULL; 



vector<amObjeet*> : : COnst_iterator ptr. 
getMutex () ->acquire ( ) ; 

//iterate the vector 

for (ptr = ms _amOb jectArray . begin () ; ptr ? = ms_amOb jectArray . end () ; 
ptr**) { 

tmp = (amObject* )( *ptr > . 

if (tmp Si w strcmpl moduieName. tmp->getModul eName ( ) ) == 0) ( 
amPtr = tmp; 
break • 

)//end if 
) / /end for 

getMutex ( ) ->release ( ) ; 

return amPtr; 

)// end f indSimEntity 



// 

// Function Name: registerObjecc ( ) 

// Task ask the RTI for a unique Object ID 

// register the Object as and Entity State Object in the RTI 
// Return Value. RTI : : Obj ectID 

// 

RTI : Object ID Admin r egisterObject ( 1 { 

RTI; ; Object ID oid = 0; 
if ( Admin: :ms_rtiAmb ) ( 
getMutex ( ) ->acquire { ) ; 

RTI . :ObjectIDcount numObjects (1) . 

// get the ID from the RTI 
try( 

Admin: :»s_rtiAmb->requestID( numObjects. oid. oid ); 

) 

catch (RTI ; Exception! e) 

l 

cerr << "requestID* << endl; 
cerr « fce « endl, 

) 

// register the ID as an Entity State Class Object 
try ( 

Admin :: ms_rtiAmb->registerObject ( Admin getESClassHandle () , oid ); 



catch (RTI : : Exception*, e) 

( 

cerr « ’registerObject* << endl. 
cerr << We << endl; 

) 
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getMutex , ->release , 



»s_ri ; Amb 



getMutex , . ->release , 
) ' end if 


try i 

Admin ms_Ammunit ior.AttrHandle - Admin »s_rt;Amb 
>getAttr ibuteHandle ( ms.Ammun l t lonStr 

nr. _ES JlassHandle. 


return old. 
end register object 


) 

catch iRTI Exceptions e i ( 

cerr << "getAttr ibuteHandle* << endl. 
cerr << se << endl. 

) 


Function Name Initi 

Task requests the handle values for the user defined objects m 

the FED file from the RTI 
Return Value void 


try { 

Admin ms_DamageAttrHandle r Admin ms_rtiAmb- 
>getAttr ibuteHandle ( ms_DamageStr . 

ms_ESClassHandl * 

) 


void Admin Imt ( )( 

if ( Admin ms_rtiAmb I ( 


carch ( PT1 .Exceptions el ( 

cej-t << ‘getAttr ibuteHandle* << endl. 
cerr << se << endl 

) 


/ t RTTI for Objects 
cry ( 

Admin. ms_ESClassHandle - Admin. ms„rtiAmb- 
>getObjectClassHandle (ms_ESCiassStr ) , 

) 

catch (RTI : Exceptions el( 


n RTTI for Interactions 
cry{ 

Admin ms_CollisionInteractionHandle - 
Admin. ms_rtiAmb- 

>get Interact lonC lassHandle <ms_Coll isionlnteract lonStr 1 . 

) 


cerr << ‘getObjectClassHandle* << endl. 
cerr << Se << endl. 

) 


catch (RTI Exceptions e) ( 

cerr << *get Interact lonClassHandle* << endl. 
cerr << se << endl. 


try { 

Admin- ms_PositionAttrHandle = Admin. ms_rtiAmb- 
>getAtcr ibuteHandle (ms_PosicionStr 

ms^ESClassHandle) 


try ( 

Admin ms_EntityIdHandle = 

Admin ;ms_rtiAmb->getParameterHandle(ms_EnticyIdStr 
ms_CollisionInteractionHandle) , 


catch (RTI . Exceptions el ( 

cerr <« *getAttributeHandle* << endl; 
cerr << Se << endl; 


catch (RTI Exceptions ei ( 

cerr << •getParameterHandie* << endl. 
cerr << Se « endl. 


try ( 

Admin: .ms_OrientationAttrHandle - Admin ms_rtiAmb- 
>getAttr ibuteHandle 1 ms_Onenta tionStr , 

ms_ESClassHandle ) . 


) / / end l f 
! end Imt 


catch {RTI: ; Exceptions e) { 

cerr << ’gecAttnbuteHandle* << endl, 
cerr << Se << endl; 

) 

try ( 

Admin :• ms_VelocityAttrHandle = Admin. ms_rtiAmb- 
>getAttr ibuteHandle ( ms_VelocityStr . 


Function Name Publ IshAndSubscnbe * ) 

Task informs the RTi that this federate will publish and subscribe 

Entity State Objects and Collision Interactions 
' Return Value void 


ms^ESClassHandle) . 


void Aomin: Publ ishAndSubscnbe !) { 


catch (RTI :: Exceptions el { 

cerr << *getActnbuteHandle* <« endl, 
cerr « se << endl; 


if ( Admin :: ms_rtiAmb )( 

// 


) 


// To actually subscribe and publish we need to build 


// an AttributeHandleSet that contains a list of 
// attribute type ids (AttributeHandle) . 

// 


cerr « se « endl; 

) 


RTI. ; AttributeHandleSet * ESClassAttributes; 


cry { 

Admin : . ms_rtiAmb->publishObjectClass ( 
ms_ESClassHandle . ‘ESClassAttributes) ; 


try ( 

ESClassAttributes - RTI : : AttnbuteHandleSetFactory : create(S), 

) 

catch (RTI :. Exceptions e)( 

cerr << *RTI : -AttnbuteHandleSetFactory . : create* << endl, 
cerr << se << endl; 


) 

catch (RTI : Exceptions e) ( 

cerr << ‘publishObjectClass* « endl. 
cerr «« Se << endl; 

) 


> 

try ( 

ESClassAttr ibutes ->add (ms_Posi t lonAttr Handle ) , 


try C 

Admin . ms_rciAmb- 

>subscr ibelrsteractionClass (ms^Coll isionlnteractionHandle ) . 

j 


catch (RTI :: Exceptions e) ( 
cerr «< ‘add* << endl,- 
cerr << fce << endl; 


catch (P.TI- : Exceptions e) ( 

cerr << ‘subscnbeObjectClassAttnbute* << endl, 
cerr « Se « endl. 

j 


J 

try ( 

ESClassAttnbutes->add (ms_OnentationAttrHandle) ; 

) 

catch (RTI : Exceptions e) { 
cerr « ‘add* << endl. 


try { 

Admin : : ms_rtiAmb->publishInteractionClass { 
ms_CollisionInteractionHandle! , 

) 


cerr << Se << endl; 

) 

try ( 

ESClassAttr ibutes->add (ms_VelocityAttrHandle 1 ; 


catch (RTI :: Exceptions e) ( 

cerr << ‘publishlnteractionClass ' « endl; 
cerr << Se « endl; 

) 


catch (RTI : Exceptions e) ( 
cerr << ‘add* « endl. 
cerr << Se << endl; 

j 


ESClassAttributes->empty ( ) ; 

delete ESClassAttributes; II Deallocate the memory 

) / / end l f 


try { 

ESClassAttributes ->add ( ms _AmmunitionAttr Handle ) ; 


)//end publish and subscribe 


) 

catch (RTI Exceptions e) ( 
cerr << *add* << endl; 
cerr << se << endl; 

) 

try ( 

ESC lassAttr ibutes ->add (ms_DamageAttrHandle) , 


// Function Name: createFederationExecution ( ) 

// Task makes RTI call that creates the federation execution if one 

// does already exist 

II Return Value void 

II 


) 


void Admin- : createFederationExecution () ( 


catch (RTI Exceptions e) { 
cerr << ‘add* << endl; 
cerr << Se << endl, 


cout << ‘createFederationExecution* << endl; 


) 

try { 

Admin: -.ms_rtiAmb->subscribeObjectClassAttribute ( ms_ESClassHandle . 

•ESClassAttributes ); 

) 

catch (RTI • : Except ions e) { 

cerr « * subscr ibeOb jectClassAttribute* << endl; 


try { 

// 

// A successful createFederationExecution will cause 
II the fedex process to be executed on this machine 

// - 

Admin : :ms_rtiAmb->createFederationExecution( m_FedExecName ) ; 
Sleep ( 200C ) ; 

) 
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Publ vahAndSubscr lbe 



•atch RT! ,-ederat .onExecut lonAlreadyExifltsi. * 
<< •crei>Fed<*r«t lonExecucion" << endl, 
•f’r <« fce *< endl. 

31eep(S00l . 

atch < RTI Exception*. e ( 
c?rr << •cr»ateF<‘dfr.i’.ior.Ex»cuticn* <«• endl. 
cerr << fce <* mdl, 



end tr#.i'»F*d<!:.UionD(^cution 



end join federation 



Function Name aecTimeManagement i i 
Task seta the RTI • s time management *tate 
This federate is NOT time managed 
Return Value void 



Function Name i omFecjerat i on i 

Task makes RTI call that 501ns the federation that has been 
created 

Return Value void 



void Admin joinFederation I { 

give join ten tries to gee joined 
for tint ix = 0 ix<10.ix»»i; 
try ( 

m_federateID = Admin ms_rt iAmb-> jomFederat lonExecut ion t 
*Sim_Admin‘ , m_FedExecName . Admin 'ms_fedAmb), 

break. 

catch RTI Federat lonExecutionDoesNot&cistfc e) ( 

/ no reason to get excited fedex may not be done 



void Admin cetTimeManagement { 
try I 

ms_rtiAmb- >setTimeConstrained '' RTI RTI_FALSE >, 
ms_r: iAmb-*turnRegulat lonOf f 

> 

catch RTI Exception*, e •, { 

cerr << * setTiineManagemenf << endl. 
cerr << fee << endl, 

) 

)//end setTimeManagemer.t 



' Function Name res lgnFederate [ 

/ Task deletes federate from the fedex and destroys the federation 
/ if it is the last federation to resign 

•/ Return Value' void 



cerr << "Fed Ex does not exist trying again" 

SleepllOOOl . 

continue 

catch ( RTI : Exceptions e ) ( 

cerr << "Fatal Error - Join Failed* << endl. 
cerr << fce << endl; 
exit (0 ) . 

) 

end for 



'Sleep to ensure federate is joined 



Sleep I 3000 ) . 



endl. 



setTimeManagement { ) ; 

// - 

// The Admin class needs to determine what the RTI is 
/ going to call its class type and its attribute's types 



Admin : : Xmt ( ) , 



// 

// Function Name advanceTime I RTI FederationTime ttimel 
II Task: asks RTI if it is alright to advance time another step 

II Return Value: void 

// 



void Admin : advanceTime ! RTI ;. FederationTime ttime>( 
try ( 

Admin: : ms_rtiAmb*>timeAdvanceRequest (ttime ) ; 



void Admin . resignFederate | ) ( 

cout << "Resigning from federation* << endl, 
try { 

Admin. ms_rtiAmb->resignFederationExecution ! 

RTI • DELETE_OBJECTS_AND_RELEASE w ATTRIBUTES) ; 



catch (RTI : Exception*. el ( 

cerr << "resignFederac ionExecution" << endl, 
cerr << fce << endl; 



try { 

Admin : ms_rtiAmb->descroyFederationExecut ion {m_FedExecNarne, 

) 

catch (RTI Exception*, ej 

{ 

cerr « "destroyFederationExecution" << endl; 
cerr << *<e << endl; 

) 

)//end resignFederate 



) 

catch (RTI: '.Exception We) 

( 

cerr « "tick" << endl; 
cerr << *.e << endl; 



return events; 



>// try 

catch (RTI . : Except ion b e) ( 

cerr << * timeAdvanceRequest" << endl; 
cerr << *.e << endl; 

)//catch 



// * 

// Function Name- addModuleFunctionPointer (amObject* amObj) 

// Task: Adds the Object associated with each module to a vector that 

// will be used later to instance objects as needed 
// Return Value, void 

// 



}ll end advanceTime 



II 

II Function Name: tickRTK) 

II Task: ticks the RTi providing processing time to clear buffers 

// Return Value Boolean 

// 

RTI :: Boolean Admin .: t ickRTI ( ) 

{ 

RTI :: Boolean events; 
try ( 

events = Admin: •ms_rtiAmb->tick( ) ; 

) 

catch (RTI :: Exception fce) 

( 

cerr <« "tick" « endl; 
cerr << be << endl; 
return RTI : : RTI.FALSE; 

) 

return events; 

) 



void Admin ; addModuleFunctionPointer (amObject * amObj) { 
vector<amObject*> :: iterator ptr, 
getMutex ( ) ->acquire ( ) ; 

// looks for amObj already in vector 

ptr = find (ms_ModuleArray. begin (), ms_ModuleArray. end 0 , amObj! ; 

//if amObj in vector do not add 
if (ptr == ms_ModuleArray . end ( ) ) { 
ms_ModuleArray push_back (amObj ) ; 

) 

Admin: :ms_NumberKodules--; 
getMutex ( ) - >re lease ( ) , 

J // end addModuleFunctionPointer 



// 

// Function Name f mdModule (const char* name) 

// Task: returns pointer to the object scored in the object array that 

// corresponds to a particular module 
// Return Value amObject* 

// 



/ Function Name. tickRTI (RTI . : TickTime minTick. RTI : . TickTime maxTickl 
// Task; same as above except ticks RTI for a certain span of time 
// Return Value, void 



RTI :: Boolean Admin: : tickRTI (RTI :: TickTime minTick, RTI :: TickTime maxTick) 
RTI: Boolean events s RTI : : RTI_FAI*SE; 
try ( 

events = Admin ; .ms_rtiAmb->tick (minTick, maxTick) ; 



amObject* Admin: : findModule (const char* name)( 

amObject* tmp s NULL; 
amObject* retObj =■ NULL; 
vector<amObject*> : : const_iterator ptr; 

getMutex ( ! - >acquire {) ; 

for (ptr - ms_Modu leAr ray .begin () ; ptr != ms_ModuleArray. end( ) ; ptr**) ( 
tmp * (amObject* ) Cptr) ; 

if (tmp (■(. stremp (name, tmp->getModuleName ( ) ) == 0 ) ( 
retObj - tmp; 
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*nd addSimEnt ity 



break 
'end if 
end tor 

getMutex I * • »release i 
return retObj. 
end findModule 



Function Name ioadModule const char* name 

Task makes bamboo ca*l that loads tne name module 

Return Value void 



Function Name moduleLeaded (const char* name) 

Task boolean function returning true if module name is loaded 
false otherwise 
Return Value Boolean 



RTI Boolean Admin moduleLoaded (const char* name ( 

RTI Boolean flag - RTI RTI.FALSE. 
bbModule* mod = bbModule . f indObject I name . 

if (mod { 

flag r RTI RTI.TRUE. 

) ' / end i f 

return flag, 
i * ' end moduieLoaded 



Function Name addSimEnti ty [const char" name. RTI . ObjectID oid) 
Task adds simulation entity to the amObjectArray 
Return Value amObject* 



amObject* Admn. adds imEnt lty ( const char* name. RTI ObjectID Old) ( 

amObject* mod = Admin f indModule [name ) , 
amObject* tmp = NULL.- 
if (mod Lk mod- >isTerrain [ ) I ( 

Admin- ms_T«rrain = mod->createObject (old) ; 

)//end if 
else if (modi ( 

tmp - mod->createObgect (oid) : 
vector<a»Object *> : iterator ptr. 



void Admin loadftodu.e e 0nsc char* name ( 
bbModule* mod 

getM<.*.ex • ) ->acquire( i . 

r-.'d - bbModule load'name ms_ModuleURLi . 
getMutex / >release 
end loadModu^e 



Function Name unloadModu.e ( const char* name 

Task maxes bamboo call that unloads the name module 

Return Value void 



roid Admin- unloadModule * const char* name ( 
bbModule* mod, 

mod =■ bbModule f indObject (name » . 
getMutex ()- >acguire ). 
bbModule . unload (mod I . 
getMutex I ) -> re lease ( ) , 
it end unloadModule 



Function Name updateFederat ion (RTI : FederationTime (, newTime i 
Task iterates the amObjectArray telling each localObject to update 
the federation with their current state 
Return Value void 



getMutex < ) ->acquire ( I . 

ms_amObj ect Array push_back t tmp) . 
Admin .ms_NumberAmObjects*- ; 



void Admin : :updateFederation (RTI Federat lonTimefc newTime) ( 
amObject* tmp = NULL: 



getMutex () ->release ( 



vector<amObject*>- iterator ptr. 



) / / end if getMutex () ->acquire( ) . 

return tmp; 



// iterate the amObjectArray 

for (ptr = ms_amObjectArray .begin () ; ptr ! = ms_amObj ect Array . end () ,- 
ptr** ) ( 

tmp = (amObject *)( *ptr) ; 
if (tmp) { 

if ( tmp- >1 oca 10b} ect ( ) ) { 

tmp->sendUpdates (newTime) ; 

) / /end if. 

)//end if 
}//end for 

II do same for the terrain 
if ims_Terrain) { 

if (ms_Terrain->local0b3ect ( ) ) { 
getMutex ( ) ->acquire ( ( .- 
ms_Terram*>sendUpdates (newTime) ; 
getMutex ( ) -^release ! ) .- 

) 

)//end if 

getMutex ( ) ->releaset ) . 

}//end updateFederation 



// Function Name. display O 

// Task: iterates the amObjectArray telling each amObject to display 

II its geometry in the proper position and orientation 
// Return Value void 

// 

void Admin. : display? ) { 
amObject* tmp = NULL. 

if <ms_Terrain) ( 

ms_Terrain->display ( ) , 

)//end if 

vectorxamObject •>:: iterator ptr; 
getMutex ( ) ->acquire ( ) . 

ptr = Admin .- :ms_amObj ect Array, begin (} ; 
whilefptr 1= Admin .-. ms_amObjectAr ray. end {) )( 
tmp = (amObject •) *ptr ; 
if (tmp) 

tmp->display ( ) ; 
ptr**.- 

}//end while 
getMutex ( ) ->release ( ) ; 

)// end display 



II 

II 

II 

n 

II 

1/ 

II 

II 



Function Name receiveUpdate ! RTI . :ObjectID theObject. 

const RTI : : AttnbuteHandleValuePairSetfc theAttributes. 
RTI : : FederationTime theTime. 

Const RTI : UserSuppliedTag theTag. 

RTI : : EVentRetractionHandle theHandle > 

Task sends the handle value pair to the correct amObject. 

if the moduel is not loaded then the proper calls are made to 
load the module for the object to be updated 
Return Value void 



void Admin-. :receiveUpdate ( RTI : : Object ID theObject. 

const RTI : -AttributeHandleValuePairSetfc theAttributes. 

RTI ■: FederationTime theTime. 

const RTI .- :UserSuppliedTag theTag. 

RTI :: EVentRetractionHandle theHandle >1 

I 

// find the correct object 

amObject* tmp = Admin :: f mdSimEntity ( theObj ect ) . 

; if (tmp) { 

getMutex ( ) ->acquire ( ! ; 

tmp->receiveUpdates (theObject . theAttributes. theTime. theTag ) . 

getMutex ( ) ->release ( l , 

)// end if 

// add module if necessay or add simEntity 
else { 

cout << "Object * << theObject << * not found - adding* << endl. 

// is module loaded 

if (Admin :moduleLoaded itheTag) ) { 

cout << "adding new * << theTag << endl; 

Admin. addSimEntity (theTag. theObjectl . 

)// end if 

// if module not loaded 
else { 

cout << ‘Loading Module " << theTag << endl; 

Admin : : loadModule ( theTag ) ; 

Admin: : adds imEnt lty [ theTag . theObject) ; 

)// end else 

) / ' end else 

) / /end receiveUpdate 



•/ Function Name: receivelnteraction ! RTI : InteractionClassHandle 
// thelnteraction. 

// const RTI ParameterHandleVaiuePairSetfc theParameters. 

il RTI : FederationTime theTime. 

const RTI. .UserSuppliedTag theTag. 
n RTI :: EVentRetractionHandle theHandle 



51 



Task sends interaction data proper simEntity 



Return Value void 


pa rams -> add tgetEr.t ltyldHandie ( char*! .id sixeof!RTI ObjectID) 


void Admin rece ive Inte ract ion RTI InteractionClassHandl* thelnteract ion 
const RTI Pa ram* terHandl eVa luepai rSeti theParameter s . 


getMutex ! i - >a cqu l r e • j , 


RTI Feder.it i onTime theTime 

const RTI UserSuppi i»dTatj theTag 


try( 


RTI BventRetract lonHandle th-Handle 


Admin ms_rtiAmb >sendlnte ract ion • getCol 1 is lonlr.teract lonHandle i 
•params . theTime NULL . 


.tiAdmin ms_Interact lonFlag I > 
RTI ObjectID oid = 0. 


catchIRTI Exceptions e. ' 
ce?r << *• e << endl. 


if thelnteract ion =- ms_Col 1 is lonlnteract lonHandle ( 
RTI Attr ibuteHandle paramHandle. 
unsigned long va iuebength. 


end sendCollisionlnteraction 


for i unsigned int ix 0. ix < theParameters sir»t ix*--* ) i 

paramHandle - theParameter s getHandlei ix I. 
if paramHandle ms Ent ityldHandle )( 

theParameters getValuei ix. ichar* fcoid. vaiuetength 
} end i t 
.end for 


Function Name sendEntityUpdatejRTI ObjectID theObject. 

RTI At t r i but eHandleValuePairSet*. theAttr ibutes. 
const RTI UserSuppi ledTag theTag 

Task sends the handle value pair from an entity to the federation 

Return Value void 


find the correct object 

amObject* tmp - Admin f mdSimEnt ity < (RTI ObjectID* oid) . 
l f l tmp i 

getMutex 1 - -'acquire i i . 


void Admin sendEnt l tyUpdate (RTI ObjectID theObject. 

RTI Attr ibuteHandleValuePairSeti theAt tr ibut ea . 
Const RTI UserSuppi ledTag theTag! ( 


ttnp->r ece iveint era cc ion ! thelnteract ion. theParameters ) . 


RTI. FederationTime theTime = m_lastTime • ms_.gr antTime, 




if ( Admin; .ms_rtiAmb I ( 


getMutex ( I ->release ( i . 
) / / end if 
/end if 


II Update state of Bold 


else ( 

cout << ‘Interaction not Known * << thelnteract ion << endl . 


getMutex ( ) -xacquire I I . 


! //end else 

)' »nd if Interact lOnFlag 


try 

( 


end receivelnteract ion 

Function Name sendCol 1 is i onlnteract ion ! RTI •: Federat i onTime 

theTime RTI : ObjectID Old! 


Admin: - ms_r ti Amb->updateAttr ibuteValues ( theObject. 
t heAttr ibutes . theTime. theTag ); 

II Must free the memory 
theAttr ibutes . empty ( ) . 

> / /end t ry 

catch ( RTI :: Except ion*, ft ) 

( 


Task. sends Col 1 isi omnteraction data to federation 
■ Return Value void 


cerr << fce << endl; 
) //end catch 


void Admin: : sendCollisionlnteraction (RTI FederationTime theTime. 


getMutex ( ) ->release ! ) ; 


RTI : ObjectID old) ( 


) / /end if 


RTI: : Pa ra me t er Hand 1 eVal uePa irS e t ‘ params - NULL; 
RTI : ULong numparams 1 1 ) . 


m_lastTime - theTime. 


params = RTI . Par ameterSet Factory . ; create (numparams ) : 


) / / end sendEnt i tyUpdate 


U 


if < pBoid } ( 

Admin: ■ ms_NumberAmObjects-- ; 


// Function Name rernoveAmObject (RTI : : ObjectID Old) 

// Task. does house keeping required to remove a simEntity from the 
// federation 

// Return Value void 


II 

II It the instance is a local object 
// we should delete it from the RTI space. 

// 


void Admin: : rernoveAmObject (RTI : :ObjectID oid) ( 


if { Admin :■ ms_rt lAmb *.*. pBoid->localObj ect ( ) }( 
tryC 

Admin; ms_rtiAmb->deleteOb ject { pBoid->getEntityID{ ) . 
0.0. NULL ) ; 


amObject* pBoid = NULL; 
unsigned int ndx = 0, 


) 

catch (RTI : Exception fce ) ( 
cerr << 4e << endl; 


// check if item to be deleted is the terrain module 

if ( Admin : ms_Terram *.*. Admin :• ms_Terra m->getEntityI D ( ) =- oid ){ 


) 

)// end if 
else ( 


if (Admin . : ms_Ter r a m-> local Object ( ) ) ( 
getMutex ( ) ->acquire ( ) ; 
try ( 

Admin: ms_rtiAmb->deleteObject( Admin: ms_Terram->getEntityID( ) . 
0.0. NULL ); 

} / /end try 


// Otherwise, this is a remote object that removeObject was 
// called on. 

// - — 

//We don’t need to do anything here 
]//end else 

ms_amObj ect Array. erase (ptr) ; 
pBoid->deleteObject ( ) . 


catch (RTI: Exception fce 1 ( 
cerr << fce << endl: 


)//end if 


)//end catch 


getMutex!) ->release ( ) ; 


getMutex ( ) ->re Lease [ 1 : 

)//end if 

Admin : :ms_Terram->deleteObject ( ) ; 


)// end else 
)//end rernoveAmObject 


Admin-. ms_Terrain - NULL, 

) 

else { // not a Terrain entity 


// 

// Function Name removeModule (const char* moduleName) 

// Task: removes module object form moduel array 

// Return Value: void 

// 


//-- - - 

// Find the instance. 

// - 

vector<amObject*> :: iterator ptr; 

amObjecf tmp = NULL; 

getMutex () ->acquire ( ) ; 

for (ptr = ms_amObjectArray . begin () ; ptr ! = ms_amObj ect Array . end ( ) ; 


void Admin: : removeModule (const char* moduleName) ( 
amObject‘ tmpObject s NULL; 
amObject* tmp = NULL; 
unsigned int ndx - 0. 

// --- - 

// Find the position of this instance. 

II 

vector<amObject •>:: iterator ptr. 


ptr*«) { 

tmp = (amObject*) (*ptr) ; 


getMutex () ->acquire () ; 


if (tmp *.*> ( tmp->gecEnticyIDO =- oid) ) { 
pBoid = tmp; 
break; 

)//end if 
) //end for 


for (ptr = ms_ModuleArray -begin () . ptr Is ms_ModuleArray . end ( ) ; ptr**) { 
tmp = (amObject* ) (*ptr ) . 

if (tmp i.4 (stremp(tmp->getModuleName (). moduleName) s=0) ) { 
tmpObject = tmp; 
ms_ModuleArray . erase (ptr) ; 
break; 
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> end i £ 

) end for 

getMutex ( > - > re lease 

if , tmpObject ) 

( 

Adam :ms_NumberModuies 
delete tmpOb^ect. 

' endif 

end remove Module 



ACE_Recursive_Thread_Mucex • Admin get Mutex 
return UadminMutex 



end admin c 





Function Name check&it ityCollision i amObjecc • that I 
Task: iterates Ob^ectArray looking for collisions with other 

entities 

Return Value amObject* it collided with 



amObj ect * Admin . chcckEntityCollision , amOb^ect * that ) ( 

amObject* tmp = NULL, 
amOb} ect * retObj : NULL. 

vector<amOb) ect •> . iterator ptr. 
ptr = Admin ms_amObj ect Array begin I 

getMutex ; I ->acquire( I . 

while iptr ' = Admin ■ ms_amOb} ect Array end ' ( 

tmp - (amOb^ect * i *ptr . 
if (tmp * = that ‘ ( 

if ( tmp->checkCol 1 ision ( that ) ) ( 
retObj a tmp; 
break . 

)//end if 
) / / end i f 
Ptr-; 

) / /end while 
getMutex ( ) ->release ( 1 . 
return retObj, 

/end checkent ityCollision 



Function Name getMutex ( I 
■ Task- pointer to Admin class Mutex 
' Return Value: ACE_Reeursive_Thread_Mutex* 






n 

// EXECUTIVE SUMMARY 

// 

// File Name AdminFederateAmbassador h 

// 

// Author: CRT Stewart Liles. Naval Postgraduate School 

// Description.- Method Definitions of AdminFederateAmbassador class 
// This file defines Federate ambassador functions required for 
// proper execution in this federation 

// September 1998. Masters Thesis 



■include ’Rti.hh* 

•ifndef _AdminFederateAmbassador 
■define _AdminFederateAmbassador 



throw [ 

RTI Specif ledSaveLabelDoesNotExist . 

RTI : : CouldNotRestore . 

RTI : Federatelnternal Error ) ; 

///////////////////////////////////// 

// Declaration Management Services // 

/////// / / // // // / / // // // /////////////y 

// 3 . S 

virtual void startUpdates ( 

RTI. . Ob]ectClassHandle theClass. 

const RTI . AttnbuteHandleSeti theAttr lbut es ) 
throw ( 

RTI : : Obj ectClassNotPubl ished. 

RTI; : Attr ibuteNotPubl ished. 

RTI. - FederatelnternaiError ) , 



class AdminFederateAmbassador public RTI FederateAmbassador 

{ 

public . 

//////////////////////////////////// 

// Federation Management Services // 
//////////////////////////////////// 



virtual void stopUpdates I 

RTI : : Obj ectClassHandle theClass. 

const RTI : . AttnbuteHandleSeti theAttr lbutes ) / 

throw ( 

RTI: Ob} ectClassNotPubl ished. 

RTI: : Attr ibuteNotPubl ished. 

RTI FederatelnternaiError) : 



// 2.6 

virtual void init latePause ( 

const RTI : : PauseLabel label) // supplied C4 

throw { 

RTI; : Federa t eAlready paus ed . 

RTI : . FederatelnternaiError) ; 

U 2.9 

virtual void mit lateResume U 
throw ( 

RTI: : FederateNotPaused. 

RTI : - FederatelnternaiError) . 

// 2.12 

virtual void mitiateFederateSave 

const RTI -. - SaveLabel label) // supplied C4 
throw ( 

RTI: :UnableToPerformSave, 

RTI: ; FederatelnternaiError} , 

virtual void mitiateFederateSave ( 

const RTI : -SaveLabel label. / / supplied C4 

RTI; .-FederationTime theTime // supplied Cl 

throw ( 

RTI . . Inval ldFederat lonTime . 

RTI. . UnableToPerformSave. 

RTI: FederatelnternaiError) ; 

// 2.16 

virtual void initiateRestore ( 

const RTI :: SaveLabel label) // supplied C4 



// 3.6 

virtual void startlnteractionCeneration ( 

RTI : . InteractionClassHandle theHandle) // suppli 
throw i 

RTI . . InteractionClassNotPublished. 

RTI . : FederatelnternaiError ) . 

virtual void stoplnteract lonGeneration ( 

RTI InteractionClassHandle theHandle) / > suppli 
throw f 

RTI . . InteractionClassNotPublished. 

RTI ; FederatelnternaiError) ; 

//////////////////////////////// 

// Object Management Services // 
//////////////////////////////// 

// 4 4 

virtual void discoverOb ject ( 

RTI. ObjectID 
RTI ObjectClassHandle 
RTI FederationTime 
const RTI: - User Suppl i edTag 

RTI EventRetracnonHandle theHandle) 

throw [ 

RTI . CouldNotDiscover . 

RTI ObjectClassNotKnown. 

RTI : : InvalidFederationTime . 

RTI : FederatelnternaiError) ; 

/ / 4.5 



theObject . 
theObjectClass 
theTime 
theTag . 



supplied Cl 
supplied C4 



supplied Cl 
supplied C4 



ed Cl 



ed Cl 



U supplied Cl 
/ supplied Cl 
> / supplied Cl 
// supplied C4 
// supplied Cl 
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v.rtua. void r e{ lectAttr ibuteVai ues 

supplied Cl 
supplied C 4 
supplied Cl 
supplied C4 
supplied Cl 

'.Wow i 

RTI ObjectNotKnown 
RTI AttnbutoKotKnown 
RTI Inva 1 idFederat i onTime 
RTI Feder.ite:nt«rs Error- 



RTI Object ID 

const RTI ActnbuteHandleV- 
RTI FederationTime 
const RTI UserSuppliedTag 



Event Ret ract lonHandle 



theObjec 1 

uePairSeti t heAt tr lbutes . 
theTime 

theTag . 



theHandle , 



.rtuj 1 
const 



void r»cf iv»Intetacti t 

RTI Interact lonllaasHanule 

RTI ParameterHandleVa luepa .rSe; 4 

RTI FederationTime 

RTI UaerSupp iedTag 

RTI EventRetractionHar.dle 



throw 

RTI Interact ronClassNotKnovm 
RTI Interact ion Par asieter Not Known . 
RTI Inva 1 idFederat lor.Time 
RTI FederatelnternalError 



chelnteract ion 
theParan-et ers . 
theTime 

theTag 

theHandle 



suppl led C 1 
suppl led C4 
suppl led Cl 
suppl i»d 14 
supplied C, 



4 9 

virtual void removeObject t 



RTI 


ObjectID 


theObjeet. 


supplied Cl 


RTI 


Object Removal Rea son 


theReason . 


Supplied Cl 


RTI 


FederationTime 


theTime . 


supplied Cl 


const RTI 


UserSuppliedTag 


theTag 


suppl led C4 


RTI 


EventRetractionHandle 


theHandle 1 


supplied Cl 



throw ( 

RTI ObjectNotKnown. 

RTI InvalidFederationTime. 
RTI FederatelnternalError) . 



virtual void removeObject < 

RTI . Object ID theObjeet. '/ supplied Cl 

RTI ObjectRemovalReason theReason) >/ supplied Cl 
throw ( 

RTI ObjectNotKnown, 

RTI Inval idFederat lonTime . 

RTI FederatelnternalError) . 

4.15 

virtual void provideAttributeValueUpdate ( 

RTI : ObjectID theObjeet, II supplied Cl 

const RTI : AttnbuteHandleSeti theAttr lbutes // supplied C4 
throw ( 

RTI ObjectNotKnown. 

RTI AttnbuteNotKnown. 

RTI FederatelnternalError); 



4 17 

Virtual void reflectRetraction ( 

RTI EventRetractionHandle theHandle) // supplied Cl 



// S.7 

virtual void infonnAttributeOwnership ( 

RTI ObjectID theObjeet, // supplied Cl 

RTI AttributeHandle theAttr lbute . II supplied Cl 

RTI : FederateHandle theOwner) II supplied Cl 

throw ( 

RTI FederatelnternalError) ; 

////////////////////////////// 

It Time Management Services // 
i//////// //////////// ///////// 

If 6 10 

virtual void timeAdvanceGrant ( 

RTI ;: FederationTime theTime) II supplied Cl 
throw 1 

RTI. InvalidFederationTime, 

RTI ; TimeAdvanceWasNotlnProgress. 

RTI Federat lonTimeAlr eadyPassed. 

RTI : FederatelnternalError) ; 

//////////////////// ////////////// 

// Data Distribution Management // 
////////////////////////////////// 

II 7.4 

virtual void changeThresholds { 

RTI :Region theRegion, // supplied 

RTI : ThresholdSetfc theThresholds ) // returned 
throw ( 

RTI: : RegionNotKnown. 

RTI: FederatelnternalError); 
il 6.17 PM 9/29/96 federateAmbServices . hh 5 

protected: 

private 



•endif 



.hrow 

RTI Event Not Known 

RTI FederatelnternalError 



ownership Management Services 






virtual RTI AttnbuteHandleSeti returned C6 

re quest At t r l bu te Owner sh i pAssu jnpt lor. ■ 

PTI ObjectID theObjer- 

const RTI Attr ibuteHandleSeti. of f -redAttributes 
const RTI UserSuppliedTag theTag. 

throw 

RTI ObjectNotKnown. 

RTI Attr ibuteAlreadyOwned. 

RTI FederatelnternaiError . 

virtual RTI AttnbuteHandleSeti 
requestAttn but eOwr.ershipAs sumption 

RTI ObjectID theObjeet. 

const RTI Attr ibuteHandleSeti of f eredAttr lbutes) 
throw ( 

RTI ObjectNotKnown. 

RTI Attr ibuteAlreadyOwned. 

RTI FederatelnternalError), 

'/ 5.3 

virtual void attributeOwnershipDivestitureNoti f ication ( 

PTI : ObjectID theObjeet. // supplied Cl 

const RTI: Attr ibuteHandleSeti. releasedAttnbutesi // supplied C4 
throw ( 

RTI ObjectNotKnown. 

RTI : AttnbuteNotKnown. 

RTI FederatelnternalError). 



supplied Cl 
supplied C4 
supplied C4 



/ / returned C6 

supplied Cl 
supplied C4 



// 5.4 

virtual void attnbuteOwnershipAcquisitionNotification ( 

RTI -ObjectID theObjeet, tl supplied Cl 

const RTI : Attr ibuteHandleSeti securedAttr ibutes j // supplied C4 
throw ( 

RTI . : ObjectNotKnown, 

RTI* AttributeNotKnown. 

RTI FederatelnternalError) , 



II 5.6 

virtual RTI : : AttnbuteHandleSeti 
requestAttnbuteOwnershipRelease ( 

RTI : Obj ect ID theObjeet, 

const RTI •: AttnbuteHandleSeti candidateAttnbutes. 
const RTI: UserSuppliedTag theTag) 

throw ( 

RTI : ObjectNotKnown. 

RTI ; AttnbuteNotKnown. 

RTI ; : FederatelnternalError) ; 



II returned C6 



/ supplied Cl 
// supplied C4 
// supplied C4 



// 

// EXECUTIVE SUMMARY 

// 

// File Name: AdminFederateAmbassador . c 

// 

// Author: CPT Stewart Liles, Naval Postgraduate School 

// 

II Description: Method Definitions of AdminFederateAmbassador class 
II This file defines Federate ambassador functions required for 
// proper execution in this federation 

// 

II September 1999. Masters Thesis 

II 

» include ‘AdminFederateAmbassador . h ’ 

* include ‘Rti.hh* 

•include ‘admin. h* 

////////////////////////////////////////////////////////////////////// 
// AdminFederateAmbassador Class 

////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////// 
// Construction/Oestruction 

////////////////////////////////////////////////////////////////////// 



//////////////////////////////////// 
// Federation Management Services II 
/ / / / / / / // / III II / / / // II II / III / / / / U / / 



void AdminFederateAmbassador . initiatePause ! 
throw (RTI. . FederateAlreadyPaused. 

RTI, : FederatelnternalError ) 



{ 

// Not implemented in 10 

) 



const RTI : PauseLabel label ) 



void AdminFederateAmbassador: : imtiateResume ( ) 
throw (RTI . . FederateNotPaused, 

RTI: FederatelnternalError) 



{ 



II Not implemented in 1.0 

} 



void AdminFederateAmbassador :. initiateFederateSave [ const RTI SaveLabel 
label ) 

throw (RTI : ; UnableToPer formSave. 

RTI FederatelnternalError) 

( 

// Not implemented in 1.0 
•ifdef TEST.SAVE 

saveFlag = RTI ; RTI_TRUE; 

cerr << ‘initiateFederateSave called with label = * << label « endl; 



) 
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rt:_true 



void AdminFederat eAmba:, sade : . nit ia t eFederateSave leons: RT. SaveLabe, 

label 

RTI FederationTime theTime) 
throw (RTI • Inva 1 idFedera t lonTime . 

RTI UnableToPerf ormSave. 

RTI . FederatelnternalError 

Not implemented in I 0 



Admin »s_Inte r aetionFlag RTI 



void AdminFederateAmbassador stopInt<*ra C tionGeneration 

RTI InteractionClassHandle th-C.ass 
throw (RTI Interact lonClassNotPubl ished 
RTI Federate Interna 1 Error 

cerr << *stopINteractionGeneration* « < endl . 



void AdminFederateAmbassador. mitiateRestore const RTI SaveLabel labels 
throw [RTI Specif ledSaveLabelDoesNotExist 
RTI CouldNotRcstore 
RTI Federatelnterr.alError ) 

' Not implemented m I 0 



Admin ms_InteractionF.ag - RTI RTI_FALSE 



Object Management Services 



Declaration Management Services 



void AdminFederateAmbassador , startUpdates (RTI ObjectClassHandle theClas^ 

const RTI' AttnbuteHandleSetfc 



theAttnbutes > 

throw (RTI Ob') e c tC la ssNot Published. 
RTI- • Attr ibuteNotPubl ished. 
RTI: : Feder a t e In terna lEr ror ) 



cerr << ’AFA. startUpdates* <« endl. 



Gets called immediately in 1.0 for all classes you publish 



void AdminFederateAmbassador • ■ stopUpdates (RTI : ObjectClassHandle theClass. 

const PTI : At tr l but eHandl eSe t fc 



theAttnbutes ) 

throw (RTI ■ . ObjectClassNotPublished. 
RTI. At tr ibuteNotPubl i shed . 
RTI . FederatelnternalError ! 



cerr << “’stopUpdates* << endl. 

// 

// Never gets called m 1.0 but we will implement it for good form. 



void AdmmFederateAmbassador • : startlnteractionGeneration 
(RTI Interact lonC las sHandl e theClass) 
throw (RTI InteractionClassNotPublished. 

RTI. FederatelnternalError) 

cerr << ’startlnteractionGeneration* << endl; 



/old AdminFederateArnoassador 
theObject 

theObj ectClass . 

theTime. 



discoverObject 

RTI 



RTI 



RTI ObjectlD 

Obj ectC 1 assHandle 
Federat lonTime 



theHandle 

throw 



(RTI 

PTI 

RTI 

RTI 



Cou ldNotDiscover . 
ObjectClassNotKnown. 
Invalid? ede rati onTime . 
Federatelnterna lError ) 



const PTI UserSuppliedTag 
RTI Event Re t ra ct lonHandle 



the Tag 



nut << *AFA discovered object * << theObject << * Module * << theTag << 
endl . 

/> is this an object type I Know about 

if ( theObjectClass Admin getESClassHandle ' ) ) < 

// is module loaded 

if lAdmin moduleLoaded (theTag i > { 

Admin addSimEntity (theTag. theObject) . 

) / / end if 

// if module not loaded 
else < 

Admin- loadModule (theTag) . 

Admin addSimEntity (theTag. theObject). 

)// end else 

)// endl f 
else ( 

cerr << ‘Discovered Obect class unknown to me * << endl, 

)// end else 



)// end discover object 

void AdminFederateAmbassador : : ref lectAttributeValues 

( RTI ; : Object ID theObject. 

const RTI. AttnbuteHandleValuePairSetfc theAttnbutes. 

RTI ; . FederationTime theTime. 

const RTI :. UserSuppliedTag theTag. 

RTI: ; EventRetract lonHandle theHandle ) 

throw (RTI . :ObjeetNotKnown. 

RTI : . Attr lbuteNotKnown. 

RTI- InvalidFederationTime . 

RTI FederatelnternalError) 

( 

Admin : ; rece iveUpdate (theObject . theAttnbutes . theTime . theTag. theHandle) . 
)// end ref lectAttributeValues 

void AdminFederateAmbassador ■ : rece ivelnteraction 

( RTI . Interact lonClassHandle thelnteraction. 
const RTI : : ParameterHandleValuePairSetfc thePa rameters . 

RT I Federat lonTime theTime. 
const RTI : UserSuppl ledTag theTag. 

RTI: : EventRet ract lonHandle theHandle) 
throw (RTI ; InteractionClassNotKnown. 

RTI : : InteractionParameterNotKnown, 

RTI InvalidFederationTime. 

RTI : ; FederatelnternalError ) 



Admin : recei velnteraction ( thelnteract ion, the Pa rameters. theTime. theTag, theHand 
le) ; 



RTI .InvalidFederationTime. 

RTI FederatelnternalError) 

( 

cout << *AFA: ; removeObject* << endl; 

Admin : : removeAmObj ect (theObject ) ; 

) 

void AdminFederateAmbassador : provideAttnbuteVa lueUpdat e 
( RTI :.' Object ID theObject. 

const RTI: AttnbuteHandleSetfc theAttnbutes) 
throw (RTI ■ Ob jectNotKnown, 

RTI AttnbuteNotKnown. 

RTI. : FederatelnternalError ) 



) 

void AdminFederateAmbassador reflectRetraction ( RTI- EventRetractionHandle 
theHandle ) 

throw ( RTI : . EventNotKnown, 

RTI FederatelnternalError) 

( 

cerr « ’AdminFederateAmbassador :: ref lectRetraction : handle ^ * « endl; 

// I didn't implement this one - sorry' 



////////////////////////////////// / 
// Ownership Management Services // 
/////////////////////////////////// 



) 



void AdminFederateAmbassador 
theOb j ec t . 

theReason. 



removeObject ( RTI . : Ob jectID 

RTI: .Object Removal Re a son 

RTI: FederationTime theTime. 

const RTI :: UserSuppliedTag theTag. 
RTI: : EventRetractionHandle theHandle 



throw (RTI : Ob jectNotKnown. 

RTI : : InvalidFederationTime . 
RTI FederatelnternalError) 



// Call the other removeObject method since this should probably 
// be implemented using default parameter values. 



removeObject (theObject. theReason) ; 



RTI: : AttnbuteHandleSetfc 

AdminFederateAmbassador : : requestAttnbuteOwnershipAssumptior. 

( RTI . ObjectlD theObject. 

const RTI :. AttnbuteHandleSetfc of f eredAttr ibutes . 
const RTI UserSuppliedTag theTag) 

throw (RTI : Ob JectNotKnown. 

RTI. : AttnbuteAlreadyOwned. 

RTI: ; FederatelnternalError) 

( 

// I didn't implement this one - sorry) 

// The following is to allow it to compile with the SparcWorks compiler 
RTI ■ ; AttnbuteHandleSet* dummy r 
RTI. . AttnbuteHandleSetFactory : : create f 0 } ; 
return ’dummy. 



RTI : AttnbuteHandleSetfc 

AdminFederateAmbassador • . requestAttr ibuteOwnershipAssumpt ion 
( RTI : : ObjectlD theObject. 

const RTI :: Attr ibuteHandleSetfc of feredAttr ibutes ! 



void AdminFederateAmbassador :: removeObject ( RTI : ObjectlD theObject. 

RTI; : ObjectRemovalReason theReason) 



throw (RTI : Object NotKnown. 

RTI. : AttnbuteAlreadyOwned. 
RTI. FederatelnternalError) 



throw (RTI .: Obj ectNot Known. 



I didn't implement this one sorry 



7h«* following is to allow it to compile with the SparcWorks compiler 
RTI Attr ibuteHandl-/et* dummy ^ 

RTI At t r l but eHandle Set Factory createjOl. 
return 'dummy. 


void AdminFederateAmbassador t imeAdvanceCrant 1 RTI FederationTime theTime 
throw (RTI InvalidFederationTime 

RTI TimeAdvanceWaaNotlnProgreis. 

RTI Federat lonTimeAlreadyPaosed. 

RTI FederatelnternalError 


void Admin re derate Ambassador attr ibutevwn<*rshipDiv**sti tus<»Not i f icat ion 
RTI ObjectID theObject. 

const RTI Attr ibuteHandleSecw re leasedAtt r ibutes 
throw (RTI Object Not Known . 

RTI Att : ibut -Not Known 


1 Set the t .me granted to and the flag to let me know 
t ime has changed 


RTI FederatelnternalError ■ 

I didn't implement this one - sorry* 


Admin ms_grantTime i theTime 

Admin. ms_t imeAdvCrant ; RTI RTI_TRUE . 


void AdminFederateAmbassador attnbuteOwnershipAcquisit lonNot 1 f 1 cat ion 
RTI .Object ID theObject 

const RTI Attribute eHandleSetfc securedAttr lbutes 
throw (RTI. ObjeetNotKnown. 


1 1 n t / i i i / i 1 1 u u n i u 1 1 un n n t i,/i 1 1 n 1 1 1 1 n n t f / > 

Data Distribution Management - NOT IMPLEMENTED IN 1.0// 
,/////////////////#////////'////////////////////////////// 


RTI Attr ibuteNot Known 
RTI . Federa* einternalError ■ 


void AdminFederateAmbassador changeThresholds RTI Region theRegion, 

RTI ThresholdSetfc tp.eThresholds 


' I didn't implement this one - sorry* 


throw (RTI RegionNot Known . 

RTI FederatelnternalError I 


RTI - • AttnbuteHandleSetfc 

AdminFederateAmbassador requestAttributeOwnershipRe lease 
( RTI • ObjectID th-Object 

const RTI AttnbuteHandleSetfc candidateAt tributes . 
const RTI . UserSuppliedTag theTag I 
throw (RTI: ObjeetNotKnown 

RTI: Attr ibuteNot Known. 

RTI: FederatelnternalError) 

I didn't implement this one - sorry! 

The following is to allow it to compile with the SparcWorks compiler 
RTI . Att r xbuteHandleSet • dummy - 
RTI Attr lbuteHandleSetFactory create (0) , 
return 'dummy, 

void AdminFederateAmbassador in formAttnbuteOwnership 
( RTI: ObjectID theObject. 

RTI. . AttributeHandle theAttnbute. 

RTI- FederateHand le theOwnerl 
throw (RTI : . FederatelnternalError) 

/ I didn’t implement this one - sorry* 

■ * 7 !/ 1 1 n u n n 1 1 u t n n ii n / 

■ Time Management Services // 


// Not implemented in 1.0 


// EXECUTIVE SUMMARY 

// 

// File Name: amObject. h 


void setVelocity (npsVec3f ) , 
void setAmmunit ion( int ) ; 
void setDamage ( float) ; 


// 

// Author CPT Stewart Liles. Naval Postgraduate School 


// RTI ambassdor interface 

virtual void sendUpdates ( RTI FederationTime theTime) r 0; 


7 Description, pure virtual class defining the interface between 
// adminModule objects, the federate Ambassador and rti ambassador 

// 

// September 1998. Masters Thesis 


virtual void sendUpdates (RTI ObjectID, RTI AttributeHandleValuePairSetfc, 
RTI .: FederationTime. RTI: .UserSuppliedTag) = 0; 


■include 'npsQuaternion . h* 
■include *npsVec3f h* 
■include 'Rti.hh* 


virtual void sendlnteraction (RTI . : InteractionClassHandle, 
RTI : : ParameterHandleVa luePairSetfc . RTI : Federat lOrTime . 
RTI: .UserSuppliedTag) =- 0, 


•include *ace/OS.h* 

■ifndef _amObject 
■ define _amObject 


// FederateAmbassador interface 
virtual void r eceiveUpdates ( RTI : :0bjectID Old. 
const RTI : AttributeHandleValuePairSetfc ta. 

RTI .: FederationTime ft, RTI :: UserSuppliedTag tag) - 0; 


■ifndef SIM.API 
•ifdef VISUALCPP 

•define SIM_API declspec (dl limport ) 

• else 


virtual void receivelnteraction (RTI . InteractionClassHandle. 
RTI: ParameterHandleValuePairSetfc RTI ; FederationTime, 
RTI. : UserSuppliedTag) r 0; 


■define SIM_API 
•endif 
■endi f 


virtual void receivelnteraction (RTI :: InteractionClassHandle. 
const RTI: ParameterHandleValuePairSetfc i = 0, 




// Object display 


class amObject 


virtual void display)) s 0; 


public : 

II member variables 


virtual amObject* createObject (RTI : ObjectID) - 0; 


RTI : :ObjectID entitylD; 

npsVec3f position. 


virtual void deleteObject ( ) = 0; 


npsQuaternion orientation; 

npsVec3f velocity; 


virtual char* getModuleName ( ) = 0; 


int ammunition; 

float damage: 


virtual RTI: : Boolean localObject ( ) = 0; 


amObject (RTI : ; Object ID) , 


virtual RTI: Boolean checkCollision (amObject* that) r 0; 


amObj ect ( ) ; 


virtual float checkTerrainCollision [amObject * that)= 0; 


//getters of Entity State fields 


virtual RTI: Boolean isTerrainO =• 0, 


RTI: .ObjectID getESititylD ( ) ; 
rpsVec3£ getPositionf ) ; 


} ; // end amObject 


npsQuaternion getOnentat ion ( ) ; 

npsVec3f getVelocity ( ) ; 

int getAmmunition ( ) , 

float getDamage ( ) , 

//setters of Entity State fields 

void set EntitylD) RTI : ObjectID); 

void setPosition(npsVec3£) ; 

void setOnentatxon (npsQuaternion) ; 


•endif 
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EXECUTIVE SUMMARY 
File Nasi** amObject.c 

• i Author CPT Stewart Lil*s. Naval Postgraduate School 

amBoid Files 

Description Defines the base object that must be inherited by ail 
participating in the federation 

September 1998. Masters Thesis 



♦include 'amObject h* 

amObject amObject {RTI ObjertID oid) { 
entltylD ^ old. 

)// end amObject 
amObject. amObjectnO 



//getters of Entity State fields 



RTI Object ID 

npsVec3 f 

npsCuatermon 

npsVec3f 

int 

float 



axnObject. getEntityID( ) ( return entltylD.) 
amObject getPosition () (return position.) 
amObject: . getOnentat ion ;) {return orientation. ) 
amObject getVelocity (){ return velocity.) 
amObject- getAmmunit ion () (return ammunition,) 
amObject. getDamage ( ){ return damage.) 



//setters of Entity State fields 



void 

void 

void 

void 

void 

void 



amObject :• setEntityIDSRTI : ObjectlD old) (entltylD = old.) 
amObject setposition (npsVec3f number ) (position = number.) 
amObject - setOr lentation (npsQuatemion number ) (orientation 
amObject setVelocity (npsVec3f number ) (velocity - number,) 
amObject setAmmunitiontint number! (ammunition = number,) 
amObject- setDamage ( float number I (damage = number,) 



number. . 



This is the module.txt for the amBoid module 



Bamboo 1 . Ob 
4 

npsVisualModule 
bbKeyboa r dModu 1 e 
nps FI y i ng Ca me r a Modu 1 e 
amHLAAdmin 
amChecker board 



// 

// 

// 

// 



EXECUTIVE SUMMARY 
File Name, module h 

Author. CPT Stewart Liles. Naval Postgraduate School 

Description: defines methods pertinent to module loading and unloading 
September 1998. Masters Thesis 



•ifndef module 

♦define module 



// INCLUDES AND EXTERNS 

n 



// 

// DEFINES 

// 



// 

// FUNCTION PROTOTYPE SPECIFICATIONS 



♦ if de £ cplusplus 

extern *C* ( 

♦endi f 

ADMIN_API const char ‘getModuleName ( ) . 
ADMIN_API float getModu leVers ion ( ) , 
ADMIN_API const char 'getModuleDate ( ! ; 
ADMIN_API const char "getModu 1 eText () ; 
ADMIN_API bool initModule ( ) ; 

ADMIN_API bool exitModule () ; 

»ifdef cplusplus 

); 

♦endif 



INLINED MEMBER FUNCTIONS 



•endif // module 
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EXECUTIVE SUMMARY 
Fil«- Nam«- module c 

Author CPT Stewart Li es Naval Postgraduate School 

Description delinks methods pertinent to module loading and unload. ng 
oeprernber 1999 Master-. Thesis 



INCLUDES AND EXTERN. 



•include <stdio h> 

•include tstdlib h> a’o f 

•include ’module h’ 

•include *am8oid h* 



CODE 









EXECUTIVE SUMMARY 
File Name amBoid h 

Author CPT Stewart Liles. Naval Postgraduate Schoo. 

Description delines methods pertinent to module loading and unloading 
September 1999, Masters Thesis 



• ilr.def _amBo.d 

• lelir.e »mBo;d 



INCLUDES AND EXTERNS 



DEFINES 



• onst char 'ge’ModuleName ; ) 

{ 

return ’amBoid" 

float getModuleVersioni ) 

{ 

return I 0. 

) 

•'.nst char ’g^tModuleDate () 



FUNCTION PROTOTYPE SPECIFICATIONS 



void imtamBoidU. 
void exitamBoidtl, 



return *1998/09/01 06 OS 48* | >> INLINED MEMBER FUNCTIONS 

) ■' 



const char ’getModuieText ( l »endi£ // 

( 

return ‘This is a really nice module*. 

) 

bool lnitModulei) 

C 

imtamBoid ( ) . 
return l, 

) 

bool exitModulet) 

( 



exitamBoid t ) . 
return 1: 

) 



// 

// EXECUTIVE SUMMARY 

// 

// File Name: amBoid. h 

// 

/ Author: CPT Stewart Liles. Naval Postgraduate School 

// 

// Description; defines methods pertinent to module loading and unloading 

// 

// September 1998. Masters Thesis 

// 



// 

// EXECUTIVE SUMMARY 

n 

U File Name am8oid.C 

// 

// Author: CPT Stewart Liles, Naval Postgraduate School 

// 

// Description: defines methods pertinent to module loading and unloading 

// 

// September 1998. Masters Thesis 

// 



•ifndef _am8oid 
•define _amBoid 



// 

// INCLUDES AND EXTERNS 



// 

// DEFINES 

// 



// 

// FUNCTION PROTOTYPE SPECIFICATIONS 



void imtamBoid ( . 
void exitamBoidtl. 

// 

// INLINED MEMBER FUNCTIONS 



•endif // 



// 

// INCLUDES AND EXTERNS 

// - 



•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 



" Rti . hh* 

’amBoid . h* 
’npsVisual .h* 
’npsWindow. h" 

" npsViewpor t . h • 
•npsFlyingCamera . h* 
'bbMouse . h* 
•bbScreen . h* 
•bbKeyboard . h* 
’bbEventResponse h* 
"bbCallback . h* 
’npsGeometry . h* 
•bold h* 

‘ amHLAAdmm . h* 
'admin, h* 

’amObject h* 

<math .h> 

<GL/gl . h> 



•ifdef SGI 

•include "bbSGI.h* 
•endi t 



// 

/ / CODE 

// 

Bold ’myBoid; // global local object 



//function prototype 
int mouselnWmdowO ; 



// 

// Function Name initamBoidd 

// Task: initialize Module -- this is run only once 

// Return Value: void 

// 

void imtamBoid ( ) { 

void initXeyboardModule ; . 
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iid lnit VisualMoaul** 



myBoid = new Bold!). 

Admin addModuleFunct i, n> ■ nt «*. myBo.d 
mi tKeyboardModule 


remove remote amcbjer 

amCbject* t.neObject Adm.: f. ..r 1 -ty ' ‘amBc _ J* 

while theObject 

Admm r»moveAjirjb)*”' t“ie'jt> ( ^ct -jetEntitylD 
thenb'eot - Adnin f ir.dSimEr.t;'-, ‘amBoid’ 


myBoid - NULL. 

couc << 'amBoid Module loaded* << end. 


remove c o.e modu.e from modu.e list 

Admin rwov»Hodu> ‘amBoid* 


end initanBoid 


-r.d exit amB .d 


Function Name exitamSoid; 

Task does housekeeping required to exit the Module -- 

this is run only once 
Return Value void 


Function Name initKeyboardM ..dule < 
Task a ad keyboard ca.iba'-ks 

Return Value void 


void exitamBoid ( ! < 


old imtKeyboardModule ( ) ( 


bbCallbackHandier *ca UbackHandler . 
uint numCal 1 backs . 

umt currCal Iback. 


void e S cFunc (bbOb j-ct ‘object bbData ‘data . 
void reset rune (bbObj ect ‘object. bbData ‘data) 
void loadBoid ibbObject ‘object bbData ‘data;. 


bbCallback ‘callback, 

uint currOuck; 

npsGeometry *duck. 

bbKeyboard* keyboard; 


bbKeyboard ‘keyboard. 

bbEventResponse ‘eventPespor.se 

bbCallbact ‘callback. 


bbEventResponse* eventResponse . 


// get the keyboard device 
keyboard i bbKeyboard .getlnstance 


. remove keyboard callbacks 
, RESET 

eventResponse = bbEventResponse f indObject I *amBoid£R_Reset * ) . 
callback = bbCallback : indObject t "amBoidReset* ) 
eventResponse->removeCal Iback [ca 1 Iback) .- 
delete callback. 

' ! remove keyboard callbacks 


’ / set up reset key 

eventResponse = new bbEventPesponse bbKeyooard KEY_SPACE! . 

eventResponse ->setName i ‘amBoid£R_Reset * • 

callback : new bbCallback 1 1 . 

call back- > sec Func (resetFunc 

ca llback-> set Name ( * amB o id Reset ‘ ) , 

eventResponse->addCallbackLast (callback , 

<eyboard->addEventP.esponse eventResponse) . 


/ / LoadBoid 

eventResponse = bbEventResponse : fmdObject ( *amBoidER_LoadBoid* ) . 
callback =■ bbCallback-.findObjectl’amBoidLoadBoid*).- 
event Response- >removeCa 11 back (callback) . 
delete callback. 

/' first remove update callback 
callback : npsVisua 1 . appCallback ( ) ; 

ca UbackHandler = cal lback->getPreCal IbackHandler (> ; 
callback = bbCallback :£ indObject ( ‘BoidPreApp’ ) . 


ii set up load bold key 

eventResponse = new bbEventResponse (bbKeyboard .: KEY_B 1 
bbKeyboard- . DOWN_TRANS ) , 

eventResponse- >setName famBoidER_LoadBoid‘) , 
callback s new bbCallback!). 
cal lback->setFunc (loadBoid) ; 
callback->setName 1 * amBoidLoadBo id* ) . 
eventResponse->addCal IbackLast (callback ) . 
keyboard->addEventResponse eventResponse) ; 


if (callback) { 

cal IbackHandl er-> remove Cal Iback (callback) . 
delete callback: 

) / / end if 


/end initKeyboardModule 


// Function Name initVi sua IModule ( ) 

// Task; attache callback to PreApp callback handler in Visula Module 
// Return Value void 


//don't do anything unless there is a local bold to control 
if (myBoid) ( 


void initVisualModule ( ) ( 


position = myBoid->getPosition ( ) ; 
rotation = myBoid- >getOnentation () , 
rotation getEulers (hpr ) , 


void initCheckerboardFunc (bbObject ‘object. bbData ‘data!.- 
void preAppFunc (bbObject ‘object. bbData ‘data) : 


// Need this to control each window separtely 
// key commands won't work unless the mouse pointer 
// is in the window 


nps Window ‘window. 

npsViewport ‘viewport; 

npsCamera ‘camera. 

bbEventResponse ‘eventResponse, 


if imouselnWmdow ( ) ) { 


bbCallbackHandier ‘callbackHandler. 

bbCallback ‘callback, 

npsVeclf position, 


// update rotation 

If ( kd->getVal {bbKeyboard . KEY_LEFTARROW) ) ( // heading left’ 


npsOuaternion rotation; 

npsGeometry ‘checkerboard. 


hpr (0] -= NPS_DEG2RAD(4.0£) .- 
if ( hpr ( 0 } > NPS_?I) 

hpr (0 J -= 2 .0f*NPS_PI ; 


// pre app callback 

callback * npsVisual ; appCallback)). 


if I kd->getVal (bbKeyboard. :KEY_RIGHTARROW > ( // heading right’ 


callbackHandler = cal Iback- >getPreCal IbackHandler O ; 
callback = new bbCallback <) . 
callback->setName { "BoidPreApp* ) ,- 
callback->setFunc (preAppFunc) , 


hpr [0 3 -= NPS_DEG2RAD £ 4 Of); 
if (hpr [0] < -NPS_PI ) 

hpr (0 I *= 2 . 0 f ‘ NPS_PI ; 

) 


cal IbackHandler- >addCal IbackLast (callback) ; 


if I kd->getVal (bbKeyboard- :KEY_UPARROW) i( // pitching up? 


) // end initVisualModule 


hpr (1J NPS_DEG2RAD( 4 Of); 

if (hpr [ 1 ] > NPS_PI *0 . 495 f ) 
hpr (11 = NPS_PI‘0 4 9 S f ; 




if ( kd->getVal (bbKeyboard. :KEY_DOWNARROW) ){ ft pitching down? 


// Function Name preAppFunc (bbobject ‘object. bbData ‘data! 
// Task; defines preApp callback function -- 
// uses keyboard controls to maneuver Bold 

ii checks for collisions 

// Return Value void 


hpr ( 1 1 -= NPS_DEG2RAD(4 Of), 
if (hpr (1 ) < -NPS_PI *0 . 49 S f ) 
hpr (1 1 = -NPS_PI • 0 . 49S f .- 

) 


void preAppFunc (bbObj ect ‘object. bbData ‘data) { 


rotation . setEulers (hpr ) . // set quaternion 


void deleteMyBoid () . 

float cosh. sinh. cosp. smp. cosr . sinr. 

bbKeyboard *kd, 

npsCamera ‘camera. 

npsVecJf position. 

npsQuaternion rotation; 

npsVecJf tmpVec; 

float hpr (3); 

float velocity = 0 .- 


i // update velocity 

if 1 kd->getVal (bbKeyboard. KEY_S) t>i> kd->getVal (bbKeyboard :: KEY_A I 
) // dead stop 

velocity = O.Of; 

else if ( kd->getVal (bbKeyboard; KEY_S) // accelerate 

velocity •= 1 2£. 

else if ( kd->getVal (bbKeyboard -. KEY_A) ! // decelerate 

velocity - - 1 . 2 f ; 

else { // slow down 


kd = bbKeyboard :: getlnstance () , 

camera = npsCamera f indObject ( * AdmmCamera* ) . 


if (velocity >= O.lf) 
velocity -= O.lf. 
else if (velocity <= -O.lf) 
velocity O.lf. 
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'e loeity 



velocity ; Cl 
rise il velocity < 
veloc.ty } 01 



or 



.amp vel< ■■ lty 2 






end if mous^InWindow 

updat- position 
■ at ic RTI Obj^ttlD oid 
. i 0. 

entity collision 
>id t myBoid- »hasCoi 1 id»d ! 
float yPos 0 0. 

RTI Boolean terramFeatureCc . i lsion RTI RTI_FALSE, 

check collision with terrain 
it (Admin ms_Terrain ( 

yPos = Admin ms Terrain->check?errainColliSion (myBoid) . 
terrimFeatureColhsion - Admin • ms_Terra in->ch»ckCol 1 1 sion (tnyBoidl 



terrain is returning a y Position 
ifiyPos •- 0 0 { 

tmpVec.sec 0 Of 0 01. -1 Of . / forward 

tmpVec sea. e (velocity ) . 

rotation. xform tmpVec I .- 

position add (tmpVec) . / set vecJf 

position set(i.yPos). 

myBoid->setVeiocity( tmpVec) . 
my8oid->setPosition(position) . 
myBoid->setOrientat ion (rotat ion] . 
camera->setPosition(position) , 
earner a ->setOnentat ion (rotation) . 

) / ’ end i f 

' ' boid collided with terrain feature 
else if ( terrainFeatureCollision i ( 

tmpVec . set ( myBoid- >getVelocity (> 1 . '/ forward 

II tmpVec • scale (velocity) , 
rotation. xform (tmpVec) . 
position. sub(tmpVec) ; // set vec3f 
position. sub (tmpVec) ; 
pos it ion . sub (tmpVec) ; ft set vec3f 
position. sub ( tmpVec ) . 
position. sub (tmpVec ) ; // set vec3f 



myBr id- »*ef r lentatic.. rotation 
camera - >setPosit ion i posit ion) . 
camera- >aetor lentat ion rotation 



boid no collision 
els* ; f Old - : 0 • 

tmpVec set 0 Of 0 Of -1 C! . forward 

tmpVe.- sea . e , veioci tyl , 

rotation xform ( tmpVec) . 

position add (tmpVec), / / set v»cJf 

myBoid >setVelocity ( tmpVer 
myBoid-> set Position 'position, , 
myBoid- >setOr lentat ion rotation, . 
camera- >setposition position . 
camera- >se*or xentat ion rotation . 

) / 'end else l f 

// boid collided with entity 
else ( 

tmpV»c setlO.Of. 0 Of. -1 Ofi, .’ / forward 

tmpVec sea le (velocity) . 

rotation xform (tmpVec) . 

position. sub(tmpVec) . // set vec3f 

posit ion sub ( tmpVec ) . 

myBoid->setVelocity (tmpVec) . 
myBoid->secPosicion(position) . 
myBoid- > set Or lent at ion (rotat ion; . 
camera- >set?ositi on ( posit ion) . 
camera ->setOr lentat ion (rotation . 

cout << ’Collided with entity • << oid << endl. 

RTI FederationTime theTime - 0.0; 

myBoid- >sendCol 1 is lonlnteract ion (theTime. oid) . 

) //end else 

// check if Bold is destroyed in some way 
if (myBoid- >getDamage ( t < 0){ 
de 1 e t eMy Bo id ( ) . 

) 



> / end if myBoid 
)// end preAppFunc 



/ Function Name resetFunc (bbObject ’object. bbData ’data: 
Task: function defined for the resetBoid keyboard callback 

Return Value void 



myBoid->setVelocity( tmpVec) ; 

myBoid- >setPosition (position) ; void resetFunc (bbObject ’object. bbData *data)( 



npsCamera • 
npsVec3 f 
npsQuaternion 



camera ; 
mitPosition; 
initRotation ; 



if (mouse InWindow ( ) i.& myBoid) ( 



mitPosition . set (0 . Of . 3. Of. -10. Of); 

ini t Rotat ion. setEuler s !NPS_DEG2 RAD (18 0 . Of 1 . 0 . Of . 0 . Of > ; 



bbScreem : normalizeVal (ix. fcy) ; 

if (viewport- >getWindow ( ) ->isVal Ins ide (x. y) ) { 
flag — 1; 

) 

return flag, 

)//end mouse Inwindow 



myBo id -> set Posit ion ( mitPosition) ; 
myBoid->setOr lentat ion ( initRotation) , 
) / / end i £ 

) ft end resetFunc 



void deleteMyBoid ( ) ( 

bbCallbackHandler *ca llbackHandler ; 

bbCallback ’callback. 



II 

Function Name. loadBoid (bbObject ’object. bbData ’data) 

/ Task: function defined for the loadBoid keyboard callback 

// Return Value, void 



Admin : . removeAmObject (myBoid->getEntityXD ( ) ) ; 
myBoid - NULL; 



)//end deleteMyBoid 



void loadBoid (bbObject ’object, bbData ’data) ( 



void : 



itVisualModule ( ) 



if (mouselnWindowt ) ) ( 

cout << ’loadBoid* << endl, 
if ( 'myBoid) { 

initVisualModule ( ] . 

RTI : ; Object ID oid = Admin :: registerObj ect ( ! 
amObjeet* tmp = 

Admin ;: addSimEntity ( ’amBoid* . oid] ; 
myBoid a (Boid’)tmp; 

myBoid->setLocalObject (RTI : ; RTI_TRUE) ; 

) / / end if 
)//end if 
)// end loadBoid 



// 

// Function Name mouselnWindowt) 

II Task: cells if mouse is in the correct window to receive keyboard 

II commands 

ft Return Value: int representing boolean 

// 

int mouse InWindow ( ) ( 

int flag s 0; 

npsWindow ’window, 

npsViewport ’viewport; 

window = npsWmdow : f indObject { ’ AdminWindow* ) ; 

viewport * npsViewport: : fmdObject ( ’AdminViewport ’ ) ; 

float x.y. 

X = bbMouse : : getX ( ) , 
y = bbMouse :: getYl ) ; 
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EXECUTIVE SUMMARY 
File Name Bold h 

Author CRT Stewart Liles. Naval Postgraduate School 
Description defines bold class 
September 1998 Masters Thesis 



•include *Rci hh’ 

•include *npsVec3f h* 

•include ’npsGeometry h* 

•include *bbKeyboard h’ 

•include ’amObject h* 

•include ’admin h' 

•ifndef ADMIN_API 
•ifdef VISUALCPP 

•define ADMIN_API declspec (dllimportl 

• else 

•define ADMIN_API 
•endif 
•endi f 



class ADMIN_API Bold public amObject 



'/memeber variables 
pub lie: 

ACE_Re cur s i ve.Thr e ad_Mu t ex t heMut ex , 



// time management data memebers 
static unsigned int ms_extentCardinality . 

static RTI: -Boolean ms_timeAdvCrant . 

static RTI : : FederationTime ms_grantTime . 
static char* ms_ModuleName . 



private : 

RTI :: Federat lonTlme m_lastTlme. 
npsGeometry* myGeom; 

// Change flags for attibute values; 

RT I : : Boolean hasPositionChanged, 

RTI::Boolean hasRotationChanged. 

RTI . .Boolean localFlag.- 

// Update Control flags 



Static RTI Boolean 
static RTI Boolean 
static RTI Boolean 



ms.sendRctationUpdates 
ms_send?ositionUpdates 
ms_sendComm Interact i ons . 



member functions 
public 
Bold 

Bold RTI ObjectID id) 

void setLocalObject RTI Boolean . 

RTI Object ID ha sCo Hided) . 

virtua* -Boid , 

virtual void display ) 

virtual amObject* createObject (RTI ObjectID Old; 

virtual void deleteObject ( : , 

virtual char* getModuleName ( j . 

virtual RTI Boolean localObject i I . 

virtual RTI.. Boolean isTerraini). 

// Methods acting on tne RTI 



virtual void sendUpdates ( RTI .FederationTime newTiroe 

virtual void 

sendUpdates (RTI ObjectID.RTI AttnbuteHandleValuePairSetfc. 

RTI -. FederationTime. RTI UserSuppliedTag) . 

virtual void receiveUpdates ( RT I .ObjectID oid. 

const RTI .AttnbuteHandleValuePairSetfc hvps. 

RTI :: FederationTime ft. RTI .UserSuppliedTag tag], 

void sendColl isionlnteract ion (RTI : Federat lonTime 

newTime. RTI : .-ObjectID old), 

virtual void sendlnteraction (RTI - : Interact lonClassHandle 

RTI ParameterHandleValuePairSett RTI FederationTime. 

RTI : UserSuppliedTag 1 . 

virtual void receivelnteraction ( RTI -. InteractionClassHandle 
thelnteraction. 

const RTI : : ParameterHandleValuePairSeti the Par ameters 

virtual void receivelnteraction (RTI InteractionClassHandle ti. 

RTI : Parameter Handle Va luePa i r Set <> phvps. RTI :. Federat lonTime ft. 
RTI • : UserSuppl ledTag tag); 

virtual RTI:Boolean checked lision (amOb) ect * that); 
virtual float checkTerrainCollision(amObjecf that). 



tt Accessor Methods 
// Static Accessor Methods 

RTI :: Federat lonTime GetLastTimeU 

{ return m_lastTime, 



private • 

void initBoidGeometry ( ) . 

static void mitBoidFunc (bbObject ’object. bbData ’data); 
float distanceFrom(npsVec3f thatPos) ; 
protected : 

RTI : : AttributeHandleValuePairSet* CreateNVPSet ( ) ; 

); 



// 

// EXECUTIVE SUMMARY 

// 

// File Name- Boid.c 

// 

// Author: CPT Stewart Liles. Naval Postgraduate School 

// 

// Description; method definitions for the Boid class -- 

// Bold class represents the class that is implemented by the amArena 
it module. 

// 

tt September 1998. Masters Thesis 



•include ’RTI.hh* 
•include ’boid.h* 
•include ’npsGeometry . h* 
•include ’bbXeyboard.h* 
•include <GL/gl.h> 
•include ’admin. h* 
•include ’amObject.h* 
•include * amHLAAdmin . h * 



tl Extent data memebers 

unsigned int Bold: :ms_extentCardinality = 0, 
char* Boid: :ms_ModuleName =■ ’amBoid’; 

//////////////// ////////////////////////////////////// IttlllUliif t > 

ii Construction/Destruction 

// / // // / / / u t tt t / / / / / / / 1 // 1 tt i // 1 / / // / / / / // / // / / / / / / / 1 t ut / // 1 / / n m < 



u 

tt Function Name Boid( RTI : : ObjectID id) 
tt Task- constructor -- instance intializer 
// Return Value: void 

// 

Boid : : Boid ( RTI : : Ob j ectID id) 
m_lastTltne (0.0) ( 

setEntityIDdd) ; 
npsVec3f xx; 
xxset(O.Of.O.Of.O.Of). 
setPosition(xx) ; 
npsQuatemion yy. 
setOnentation (yy) ; 

setDamage (10.0) ; 

localFlag = RTI: :R7I_FAUSE. 

initBoidGeometry! ) ; 

Bold. :ms_extentCardinality« • ; 



61 






function Name Bo id 

Task constructor •• used tor object storage .n Modul^Array 
Return Value void 



Bold 

ir_l astTn 



0 ( 



RTI At c r ibuteHandleVa lueRair Set* pNvpS~t ■ Cr«-ar ejiVRSe' 

Admin sendEntityUpdate • getEnt.tylD . *pMvpS<*t . getfloduleName 

set m^lastTime to newTime 

m_la stTime - newTime. 

end sendUpdates 



function Name -Bold- 
Task destructor 
Return Value void 



Bold -Boidt { 

remove the Object from the 

Bold ms_extentCardinality 
if imyOomi 

delete myCeom. 

end destructor 



function Name sendUpdates ( RTI • ObjeetID Old. 

RTI AttributeHandleValuefa lrSetfc ta. 

RTt FederationTime ft. RTI- UserSuppl ledTa g tagl 
Task not implemented in this module -- pure virtual function muse 
have definition 
Return Value- void 



void Bold: . sendUpdates (RTI : :ObjectID old. 

RTI. • AttnbuteHandleValuePair Sett. ta. 

RTI -. FederationTime ft. RTI: : UserSuppl iedTag tag] 



function Name sendUpdates {RTI .. federationTime newTime ) 

Task send handle value pair to rti for update to federation 
Return Value: void 



void Bold : sendUpdates ( RTI :: federat lonTime newTime) { 



/ Update state of Bold 



)// end for 
)//end reeevieUpdates 



// 

function Name, receivelnteraction (RTI : : InteractionClassHandle ich, 
RTI ParameterHandleVaiuePairSeti phvps. PTI FederationTime ft. 
RTI : -UserSuppl iedTag tagl 

II Task: not implemented in this module -- pure virtual function must 

// have definition 
/' Return Value void 



void Boid. . receivelnteraction (RTI ; -.InteractionClassHandle ich. 

RTI - . ParameterHandleValuePairSetL phvps. RTI federationTime ft. 
RTI : UserSuppl iedTag tag) 

() 



// Function Name receivelnteraction! 

II RTI :: InteractionClassHandle thelnteraction . 

II const PTI : : ParameterHandleVa luePairSetJ. theParameters ) 
II Task. recieves PHVP and decodes for use with module 
II Peturn Value: void 



void Bold: receivelnteraction! RTI :; InteractionClassHandle thelnteraction. 

const RTI : ParameterHandleValuePairSett theParameters ){ 

if t thelnteraction Admin; getCollisionInteractionHandle( )) { 
setDamage (getDamage I ) - 1.0); 

cout << •••Collision Detected -- Object * << getEntityIDO 
<< * Damage : ‘ << getDamage { ) << endl: 

> 

) / / end receivelnteraction 



/ function Name sendCollisionlnteraction (RTI : FederationTime theTime, 
II RTI :: Object ID oid! 

// Task: sends rti the PHVP using the send interaction fuention 

// Return Value, void 



void Boid: : sendCollisionlnteraction (RTI : FederationTime theTime. 

RTI: rObjeCtID Old) ( 

//build paramter handle value pair 

RTI : : ParameterHandleValuePairSet* params = 

RTI : Parameter Setfac tory ; : created); 



Function Name r eeeiV'-Updates t RTI Object ID oid 

const RTI Attr ibuteKandleVa.ueRairSeti. th.eAttnbutes. 

RTI federationTime theTime. RTI User Suppi t edTag theTag] 
Task decodes HVP from PTI for this object 
peturn Value void 



void Boid receiveUpdates 1 PTI ObjectZD old. 

const RTI Attr lbuteHandleVa lue Pair Set t theAttr ibutes . 

RTI ; FederationTime theTime. RTI User Suppi iedTag theTag) ( 

RTI AttributeHandle attrHandle. 
unsigned long value Length. 

/ We need to iterate through the AttnbuteHandleValuePairSet 
' to extract each AttnbuteHandleValuePair. Based on the type 
ii specified ( the value returned by getHandle t ) ) we need to 
extract the data frlom the buffer that is returned by 
getValue ; l . 

for ( unsigned int i - 0. i < theAttnbutes . size | ) . i*» , 

( 

attrHandle - theAttr ibutes getHandl* i i ]. 

if ! attrHandle z? Admin getPositionAttrHandle ) ) 

< 

npsVec3f tmp; 

theAttr ibutes . getValu' ! l. (char*)4tmp. valueLength ). 
setPosition (tmp) . 

)//end if 

else if l attrHandle as Admin : getOnentationAttrHandle : ) 

( 

II Same as above goes here... 
npsQuatemion tmp. 

theAttr ibutes . getValue ( i. (char*)4tmp. valueLength ); 
setOr lentation ( tmp] ; 

I / / end else i f 

else if [ attrHandle == Admin :: getVelocityAttrHandle ( ) ) 

( 

/ / Same as above goes here . . 
npsVec3 f tmp. 

theAt tributes . getValue [ i. (char * ) ttmp . valueLength ); 
setVelocity(tmp) . 

)// end else if 



params->add (Admin: : getEntityldHandle () , (char*) fcoid. 
sizeof (RTI ObjectID) ) ; 

sendlnter act ion (Admin: : getColl is lonlnteract ionHandle ( ) . 'params. 
theTime. NULL) ; 

)//end sendCollisionlnteraction 



// Function Name sendlnteraction (RTI ; FederationTime ft) 

// Task: send the PHVP for the given interaction 

// Return Value, void 

// 

void Boid sendlnteraction (RTI : InteractionClassHandle ihc. 

RTI :; ParameterHandleVa luePairSeti phvps. RTI FederationTime ft. 
RTI ; . UserSuppliedTag tag) ( 

try{ 

Admin: : ms_rtiAmb- >sendInteraction ( ihc . phvps . ft. tag) ; 

) 

catchlRTI .. Exceptions e) ( 
cerr << te << endl; 

) 

)//end sendlnteraction 



// 

// Function Name Cr eateNVPSet I ) 

// Task: creates HVP set pertinent to this object 

II Return Value AttnbuteHandleValuePairSet’ 

// 

RTI : Attr ibuteHandleVal uePair Set* Boid : :CreateNVPSet ( ) { 

RTI : ■ AttnbuteHandleValuePairSet* pBoidAttnbutes = NULL; 

// Make sure the RTI Ambassador is set. 
if ( Admin ms_rtiAmb ) 

{ 

// 

// Set up the data structure required to push this 
// objects *s state to the RTI. 

// - 

RTI : ; Object IDcount numAt tributes (3 ) ; 

pBoidAttributes = RTI : : AttnbuteSetFactory :: create ( numAttributes ); 

pBoidAttributes->add ( Admin: : getOr lentat ionAttrHandle t ) . 

(char*) fcorientation, 
sizeof (npsOuaternion) ). 

pBoidAttributes->add ! Admin: getPositionAttrHandle'.). 

tchar*) ^position, 
sizeof (npsVec3f) ); 
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pBc idAc tributes- -add ( Admin getVeloeicyAttrHandle i 

ichir'i ^velocity 

sireof ( npsVec3 f i ). Function Nasn«- mitSc idFur.c (bbODjecr ’object bbData "data 

Task defines (unction for geometry cal. back 
Return Value void 



return pBoidAttr ibutes. 
Cr eateNVPSet 



Function Name- display) 1 

Task updates geometry position and orientation 
Return Value void 



void Bold .displaylit 

myGeom->setPosition (getposition ( ) ! . 
myGeom->set Orientation ( getOrientation ( ) ) . 

' > end display 



/ Function Name createObject ( RTI ObjectID old) 

' Task creates an object and returns a pointer to it 
' Return Value amObject* 



amObject* Bold • createObject ( RTI .ObjectID oid){ 
Bold* tmpBoid - new Bold (Old), 
return ( amObject * ) tmpBo id, 

)//end createObject 



// Function Name deleteObj ect ( ) 
'/ Task. remote delete function 
'/ Return Value, void 



void Boid . : deleteObject ( ) { 
delete this; 



/ Function Name getModuleName ( ) 

/ Task; accessor method for module name 
Return Value char* 



char* Bold: : getModuleName () ( 
return Bold .ms_ModuleName ,* 
)// getModuleName 



// 

// Function Name set Local Object (RTI rBoolean flag) 
// Task: set the object as local or not 

II Return Value: void 

II 

void Bold. -setLocalObjecttRTI : Boolean flag) ( 
loealFlag = flag. 

) 



:d Boid inicBoidFunc (bbOb)-rt ’object. bbOata ’data ' 



CLfloat coords 1 4 ) 15) : < ( 0 0£ 0 Of. -0 91/ 

(-0 6i 0 Of. 0 9t > 

( C 6f 0 Of 0 9f . 

< 0 Of. 0 6i. 0 9i • 



glShadeModei iCL_FLAT> . 
gl Begin (GL_TR I ANGLES ) . 

{ 

glColor3f (0 Of. O.Sf. 1 Ofi. / bottom 
glVertex3fv (coords(O) ) . 
glVertexi fv coords (1 ] ) . 
glVertex3fv<coords ( l ) ) . 

glColorJf 1 1 Of. O.Sf. 0 Of). // left 
glVertex3fv (coords [ 0 ) ) . 
glVertex3fv(coords (1) ) . 
glVertex3£v(eoords{3) ) . 



glColorJfd Of. 0 Sf. l.Ofl; /' right 
glVertex3fv(coordsf 01 ) , 
glVertex3fv (coords (3 I ) . 
glVertex3fv (coords (2 1 ) . 



glColor3ft0 Of. O.Sf. OOf). // back 
glVer :ex3fv (coords ( 1 ) ) . 
glVercex3 fv (coords (21). 
glVertex3fv (eoords(3) ) . 



' front 
back left 
oack right 
/ top 



glEnd ( ) . 

glShadeModei (GL_ SMOOTH) . 
)//end mitBoidFunc 



'/ Function Name initBoidCeometry ( ) 

Task attaches the function for geometry callback to the Visual Module 
/ Return Value void 



void Boid . initBoidCeometry () { 

myCeom = new npsCeometry (Bold : : initBoidFunc) . 
myGeom->secBoundmgSphere (npsVec4f (0 .Of . O.Of. O.Of. 1 . Of > ) . 

)// end initBoidCeometry 



II loop amObject array 
// compute distance 
RTI. Object ID oid = 0; 

amObject* tmp = Admin : rcheckEntityCollision (this) ; 
if (tmp (tmp J = this) )( 

if ( ( ( tmp->getVelocity ( ) ) . length ( ) < (this->get Velocity { ) ) . length ( ) ] ] ( 
oid = tmp->getEntityID ( ) ; 

) / / end if 
)//end if 



// 

// Function Name- localObject [ ) 

// Task: accessor method for local object flag 

// Return Value Boolean 



RTI : : Boolean Boid : localObject ( ) ( 
return loealFlag; 

) 



return oid, 
}//end hasCollided 



// 

// Function Name. distanceFrom (npsVec3f thatPos) 
// Task finds distance between two objects 
// Return Value float 

II * 



// 

// Function Name isTerrainO 

II Task: informs amHLAAdmm whether the object is a terrain object or not 

II Return Value Boolean 

// 

RTI Boolean Boid: : isTerrain t ) ( 
return RTI: RTI_FALSE; 

) 



float Bold- : distanceFrom (npsVec3f thatPos) ( 

npsVec3f thisPos = this->getPosition( ) ; 

npsVec3f tmpPos; 

tmpPos . sub (thatPos, thisPos ) ; 

return tmpPos . length ( ) ; 

)//end distanceFrom 



// Function Name: checkCollision (amObject* that) 

// Task: retumds true if there is a collision with this object or not 

H Return Value: Boolean 

// 

RTI Boolean Bold: eheckCollisionlamObject* that) { 

RTI:: Boolean flag = RTI . : RTI_FALSE . 
if (that != this! ( 

if (distanceFrom (that->getPosition () ) < 2) ( 
flag = RTI RTI.TRUE, 

)//end if 
)//end if 
return flag, 

)//end checkCollision 



// Function Name. hasCollided ( ) 

// Task: cheeks if current object is collided with any other obaject 

// Return Value ObjectID 



// Function Name- checkTerrainCollisionlamObject* that) 
u Task returns y value for terrain to provide rudimentary terrain 
// collision detection -- 0.0 because not a terrain module 
// Return Value void 

// 

float Boid : • checkTerramCollision (amObject* that) { 
return 0.0; 

) // end checkTerramCollision 



RTI ObjectID Bold: : hasCol lided ( ) ( 



This n 



the module txt 



for amArena module 



amArena Files 



Bambool Ob 

bbKeyboa rdModu le 
npsVi sua 1 Module 
amHLAAdmm 



// 

// EXECUTIVE SUMMARY 

// 

// File Name module. h 

// 

// Author: CPT Stewart Liles. Naval Postgraduate School 



// Description: This file defines the global functions required by every 
// dynamically- linked library. How these functions are 

implemented is arbitrary, but it is useful have RCS 
automate some of the work. 

// September 1998. Masters Thesis 

// 



•ifndef module 
•define module 



II 

// INCLUDES AND EXTERNS 

// 



// 

// DEFINES 

// 



/ FUNCTION PROTOTYPE SPECI FICATIONS 



•ifdef cplusplus 

extern *C* { 

•endi f 

ADMIN_API const char * getModuleName ( ) ; 
ADMIN_API float getModuleVersion!); 
ADMIN_API const char ‘getModuleDate ( ) ; 
ADMIN_API const char ’getModuleText () ; 
ADKIN_API bool initModulei) ; 

ADMIN_API bool exitModuie ( ) ; 

•ifdef cplusplus 

>; 

•endi f 

•endif // module 



// 

// EXECUTIVE SUMMARY 

// 

// File Name, module. c 

// 

// Author: CPT Stewart Liles, Naval Postgraduate School 

// 

// Description: This file defines the global functions required by every 
// dynamically- linked library. How these functions are 

// implemented is arbitrary, but it is useful have RCS 

II automate some of the work. 

II 

II September 1998. Masters Thesis 

// 



// INCLUDES AND EXTERNS 



•include <stdio.h> 

•include <stdlib.h» II atof 

• include ’ module. h’ 

•include ‘amArena. h* 



// 

// DEFINES k FILE SCOPE VARIABLES 

// 



II 

// CODE 



const char ‘getModuleName 1 ) 

{ 

return ’amArena*; 

) 



float getModuleVersion () 

{ 

return 1 .Of; 

) 



const char ‘getModuleDate () 

{ 

return *1998/08/01 06:00:48’; 
) 



const char ‘getModuleText ( » 
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•eturn *amAx'>f 



T-rrain module 



T 



L ->ad* , 



bool imtModulei) 

< 

imtamArena i . 
return 1. 



bool exi tModule ( 

( 

exi tamArena ( 
return 1. 



EXE UTIVE SUMMARY 
Fi.e Name arvArena l. 

Author PC Stawjrf Liles Naval Postgraduate School 

description defines methods per* men? to module loading and unloading 
September 1 J'i" Masters Thes.s 



• fndef _amArena 
•detine _amArena 



INCLUDES AND EXTEPN" 



DEFINES 



FUNCTION PROTOTYPE SPECIFICATIONS 



void imtamArena ( I . 
void exitamArena ( j , 



INLINED MEMBER FUNCTIONS 



// 

// EXECUTIVE SUMMARY 

// 

// File Name. amArena . c 

II 

// Author CPT Stewart Liles, Naval Postgraduate School 

II 

// Description: defines methods pertinent to module loading and unloading 
// September 1998, Masters Thesis 



// prototypes 

void initKeyboardModule () , 
void initVisualModule( ) , 

II instance a Arena Object and pass it to the module array 
myArena = new Arena ( ) , 

Admin addModuleFunet lonPointer (myArena ! , 

II this is a Terrain module so if one already exists we must delete it 
if (Admin: ms_Terrainl { 

Admin unloadModule [Admin; .ms_Terrain- >getModuleName m ; 

)//end if 



// 

II INCLUDES AND EXTERNS 

// 



•include 
» include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 
•include 



'Rti.hh* 

•npsVisual h* 
•npsWindow h* 
•npsViewport h' 
•bbMouse h* 
•bbKeyboard h* 
•bbEventResponse h* 
'bbCallback. h* 
•npsGeometry .h* 
'Arena h' 
'amHLAAdmin h* 
'admm . h* 

•amObject h* 



•include <math h> 
•include <GL/gl h> 



initKeyboardModule ( ) ; 

II null my Arena for future use 
myArena = NULL, 

// add object to the federation 
if ( 'myArena i { 

RTI : Object ID oid - Admin. registerObjeet < > , 
amObject* tmp : Admin .: fmdModulet 'amArena* \ . 

npsGeometry* arenaPtr = npsCeometry • fmdObject ( *amArer,a_Geom* ) . 
l f ( (arenaPtr ) ( 

initVisualModule i i , 

) 

myArena = (Arena • | tmp->createObj ect (old > . 
myArena ->setLoca iObject (RTI • RTI_TRUE) . 

Admin . . ms_Terrain = myArena, 

)//end if 

// this allows Arena to update to rest of federation 
l £ (myArena ; { 

myArena ->setUpdateF lag (RTI . PTI_TRUE) . 



•ifdef SGI 

•include 'bbSGI.h' 
•endif 



cout << ' imtamArena* << endl, 
)// end imtamArena 



/ / CODE 

// 

Arena ‘myArena, 

int mouselnWmdowf J . 



// Function Name imtamArena O 

// Task initialize Module -* this is run only once 
// Return Value void 

// 

void ini tamArena ( 1 ( 



II Function Name exitamArenad 

II Task: does housekeeping required to exit the Module 

/ t this is run only once 
II Return Value void 



void exit amArena ( ( ( 

bbCal IbackHandler ‘callbackHandler , 
bbCallbacfc 'callback. 

bbKeyboard* keyboard; 

bbEventResponse* event Response . 

keyboard = bbKeyboard: get Instance i. 

II remove keyboard callbacks 
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keyboard- /addEvent Response : /-vent A**sponse , 



'adArcna c»Ubsc-v 

rv^ntReapons? - bbEv» , nt.P^^ponu'* Obm. * • amArenaER_Ter r am" 

>-i..bsck - bbCallback t indob) »"" * 1 ai\Ar'r,« Terrain*), 

fVontP'spons' -> remove Ca 1 .back ca 1 . back 
delete callback. 



remove rKmote amObjects 
itiAdm.n n'S.Tsrr-uni ( 

Admin removeAmOb ect Admin 



Terrain » 7*»t Ent icylD , ) I 



••move local object 
•myArena ( 

npiG'-oin't ry * crap npsGe'-metry fmdOojer:. 'amArena_Geom* ) . 
i l ( tmpi 

delete trap 



Function Nam« initVisualModule i 
Task set the geometry for the Arena 
Return Value void 

/id imtVisualModu.e i ( 

void lnitArenaFunc bbObject 'object bbData *dat4i . 
npsGeometry 'arena. 



remove the module trom module 
Admin removeModule • 'amArena' . 

Admin ms„Terrain NULL,. 

rout << ' exitamAr tna ' << endi. 



• mit geometry 

arena = new npeGeometry ( ini tArenafunc 1 . 
arena ->oetName *amArena_Geom* ) . 

>) end initVisualKodule 



end exitamArena 



Function Name initKeyboardModule 1 1 
Task add keyboard callbacks 
Return Value void 



void ini tKeyboardModu le ( j 



void escFunc (bbObj ect 'object. bbData 'datai . 
void resetFunc [bbObject 'object. bbData 'data), 
void loadArena (bbObject 'object. bbData 'data), 

bbKeyboard 'keyboard; 

bbEvent Response 'eventResponse . 

bbCallback 'callback, 

get the keyboard device 
keyboard = bbKeyboard :getlnstance ), 



• set up load bold key 

eventResponse = new bbEventResponse (bbKeyboa rd : . KEY_T | 
bbKeyboard: :DOWN_TRANS) . 

eventResponse->setName ( * amArenaER_Terrain' ) ; 
callback = new bbCa llback ( 1 . 
ca llback-> setNarae ( • amArena_Terrain* ) . 
cal iback->setFunc { loadArena 1 . 
eventResponse->addCallbackLast (callback) , 



Function Name loadArena (bbOb) ect 'object bbData 'data: 
Task: function defined for the loadArena keyboard callback 

Return Value void 



void loadArena {bbObject 'object, bbData 'data>( 
void mitVisualModule f ) , 

if (raouselnWindow ( I ) ( 

cout << 'loadArena* « endl; 

l f ( t myArcna I < 

//add Arena to federation if does not exist 
RTI . . ObjectID Old - Admin : registerObj ect ( ) , 
amObject' tmp = Admin :: f mdModul e ; 'amArena ') . 

npsGeoraetry* arenaPtr = npsGeometry • • f indOb ject ( * amAr ena_Geom* ) , 
if ( ! arenaPtr ) ( 

mitVisualModule ; ) , 

) 

myArena = {Arena* ) tmp->cr eateObject (old) . 
myArena->setLocalObject (RTI : RTI_TRUE) , 

Admin . : ras_Terrain = myArena, 

) / / end if 

//set flag so Arena is updated and the rest of the federation 
// will discover the object 
if (myArena ) ( 

myArena ->setUpdateF lag (RTI RTI_TRUEl , 

) 



glBegin [GL_TRIANGLE_ STRIP) ; 
( //start gl 



Function Name* lnitArenaFunc (bbObj ect 'object, bbData 'data) 
Task function defining the Arena geometry 
Return Value: void 



void lnitArenaFunc (bbObject 'object. bbData *data){ 
npsGeometry 'geometry, 

umt displayListNum; 

const float CELL_LENGTH = SO; 

•ifdef VISUALCPP 



const umt 
const uint 
•elif SCI 

const umt 
const uint 

•endi f 
const uint 
const umt 
const uint 
const uint 
uint 
bool 



NUM_CELLS_LONC = 10; 
NUM_CELLS_WIDE = 10; 

NUM_C ELLS_ LONG = SO. 
NUM_CELLS_WIDE = SO; 



TOTA L_NUM_C ELLS = NUM_CELLS_LONC ‘ 
NUM_VERTS_LONG = NUM.C ELLS .LONG * 
NUM_ V ERTS_ W IDE = NUM_CELLS_WIDE - 
TOTA L_NUM_ V ER TS = NUM_VERTS_LONG - 
i, j, currVert, currlndex, 
ColorToggle, 



NUM_CELLS_WIDE; 



num_verts_wide, 

currCell ; 



GLfloat 
GLf lost 
GLf loat 



coords [TOTAL_NUM_VERTS] [3] ; 
normals (TOTAL_NUM_VERTS) (3] ; 
textures (TOTAL_NUM_VERTS) [ 2 ] ; 



// mit Vais 
colorToggle = 0, 

for (i=0, i<NUM_VERTS_LONC, i**) ( 
for (j=0; j < NUM_V ERT S_W IDE; j**)[ 
currVert = i 'NUK_VERTS_WIDE ♦ j; 

coords (currVert] 1 0 J = (CELL.LENGTH ' i) - 
(NUM_C£LLS_LONG'CELL_LENGTH'O.Sf ) ; 

coords [currVert ]( 1 ) = O.Of; 
coords [currVert ][ 2 ) = ( -CELL_LENGTH * j) - 
( NUX_C ELLS _W IDE * CELL_LENGTH ' 0. Sf ) ; 

norma Is ( currVert ) [0] = O.Of; 
normals [currVert) [1] = 1.0£, 
normals [currVert) [2] = O.Of; 

textures [currVert ) [0) = ( i float ) i )/ (NVM_VERTS_LONG-l ) ; 
textures (currVert) (1) = (( float) j )/ (NUM_VERTS_WIDE-1) ; 
)//end for j 
) //end for i 

glShadeModel (GL_rLAT) . 



colorToggle = 0; 

for ( i = 0 ; i<NUM_CELLS_LONC; i*->( 



for (j=0; j<NUM_VERTS_WIDE; j-*)( 
if (colorToggle) { 
colorToggle = 0; 
glColor3f (O.Of. O.Of. l.Of); 

) 

else ( 

colorToggle = 1; 
glColor3f (l.Of. l.Of, l.Of ; 

) 

currVert = i 'NUM_VERTS_WIDE * j ,* 
glVertex3fv (coords [currVert) ) ; 

currVert = (i*l) *NUM_VERTS_WIDE * j; 
glVer tex3 fv (coords (cur r Vert) ) , 

)//end for 

if ( NUM_CELLS_WIDE t 0x1 )( 
if (colorToggle) 

colorToggle = 0; 
else 

colorToggle = 1; 

) 

)//end gl 
glEnd I) , 

) //end for 

// walls and ceiling 
//North wall 
glBegm(GL_ POLYGON) , 

glColor3f (O.Sf.O.Sf.O.Sf) , 
glVer tex3 f (-25. Of, O.Of. -2 S - 0 f ) . 
gl Vert ex3f(2S. Of, O.Of. -2S.0f) . 
glVertex3 f (2S . Of . SO . Of . -2S .0f ) . 
glVertex3f ( -2S . Of , SO . Of , -2S .0f ) ; 
glEStd l ) ; 

//South wall 
glBegin (GL_ POLYGON) , 

glColor3f (0 , « f . 0 6f , 0 6 f ) ; 
glVertex3 f (-25. Of. O.Of. 2S.0f) ; 
gl Vertex 3 f (2S. Of, O.Of, 2 S . Of) ; 
glVer tex3f { 2S . 0 f . SO . Of . 2S . Of ) , 
glVertex3f I -2S . Of , SO . Of .25. Of), 
glEJndl) ,- 
//West wall 
g 1 Beg i n ( GL — POLYGON 1 , 

glColor3f (O.ef.O.Sf, 0 4f) ; 
glVer tex3 f t-2S.0f. O.Of. 2S.0f) , 
glVertex3 f(-25.0f,0.0f,-25.0f . 
glVer tex3 f ( -25 ,0f . 50. Of. — 2 S .Of) ; 
glVertex3f ( -25 . 0 f . SO . Of . 25 . Of ) ; 
glEnd() , 

//East wall 
g 1 Beg in(CL_ POLYGON ; 

gl Co lor 3 f (0.4f.0.5f,0.8f) ; 
glVertex3f ( 25 . Of . 0 . Of , -2S . Of ) . 



66 



gl Vertex j : i 2 5 0: j Of 2 Of' 
glVercexJf (25 Of. AC Of. 25 Of 
gl Vert ex 3 f ( 2 S Of. 50 Of. -25 Of 


EXECUTIVE SUMMARY 


g 1 End t ) 

'/ceiling wail 


-lie Name Arena h 


glBegin (CL_POLYCON) . 

glColo:3 f 10 . 8f . 0 9f 0 8f>. 


Author CPT Stewart Liles. Naval Postgraduate School 


glVertex3 f ( *25 Of SC Of 25 Of 
glVertex3 f ( 2S Of 50 Of -25 Of' 
glVertex3 f i 25 Of. 50 Of. 25 Of). 
glVertex3£ 1-25 .Of. SO Of 25 Of 


Description method definitions for the Arena class - - 

Arena class represents the class tnat is implemented by the amArena 
module 


g 1 End ( ) . 


1 Septemoer 1999 Masters Thesis 


glShadeModel (GL_SMOOTH) . 
m it Arena ?unc 

Function Name mouselr.Wmdow 

Task tells if mouse is m the correct window to receive keyboard 

commands 


• include * Rc l hh* 

•include *npsVec3f.h‘ 
•include ‘npsGeometry h* 
•include ‘bbKeyboard h‘ 
•include ‘amObject h* 

• include ‘admm h‘ 


Return Value in: representing boolean 

me mouse InWmdow ( ) ( 

inc flag * 0. 

npsWmdow ‘window. 

npsViewport ‘viewport. 

window = npsWmdow f indOb} ect ( • AdminWindow" ) . 


•ifndef ADMIN_API 
•ifdef VISUALCPP 

• define ADMIN_API declspec (dl 1 import 1 

• else 

•define ADMIN_API 
•endi £ 

•endif 


viewport - npsViewport f mdobject t ‘AdminViewporf j . 
float x.y , 

x = bbMouse getX ( ) , 


class ADMIN_API Arena public amObjecc 


y - bbMouse getY I) , 
bbScreen . - norma lizeVal (fcx . ty) . 

if ( viewport -»get Window ( ) -> lsVal Inside (x.y) ) ( 
flag = 1; 


/memeber variables 
public 

/ ' Extent data memebers 
static char* ms_ModuleName . 


) 

return flag. 


pr lvate 



Change flags for attibute values 





RTI —Boolean localFlag. 

RTI.:Boolean updateFlag. it flag so only single update 




/ member functions 
public 




Arena ( ) , 

Arena ( RTI .ObjectID id) . 

void secLocalObject (RTI : : Boolean) . 

void setUpdateFlag (RTI * :Boolean ! . 




virtual -Arena () ; 







virtual void display!) ; 

virtual amObject* createOb^ect (RTI : ObjectID old); 


// EXECUTIVE SUMMARY 

// 


virtual char* getModuleName ( ) ,- 


// File Name Arena. c 


virtual RTI::Boolean localOb} ect ( ) ; 


// Author: CPT Stewart Liles. Naval Postgraduate School 


virtual RTI:;Boolean isTerrainO; 
// Methods acting on the RTI 


// Description- method definitions for the Arena class -- 

// Arena class represents the class that is implemented by the amArena 

// module 


virtual void sendUpdates ( RTI - . Federat ionTime newTime), 


// September 1996. Masters Thesis 

II * 


virtual void 

sendUpdates (RTI . rObjectID, RTI ; -AttnbuteHandleValuePairSetfc . 

RTI: : Federat ionTime. RTI : : UserSuppliedTag) . 

virtual void r eceiveUpdates (RTI : :Ob}ectID old. 

const RTI ■ AttributeHandleValuePairSetA hvps. 

RTI : : FederationTime ft. RTI •: UserSuppliedTag tag); 

virtual void sendlnteraction (RTI : -.InteractionClassHandle. 

RTI : : Par ame ter Handle ValuePairSeti. RTI : : FederationTime, 
RTI: : UserSuppliedTag) ; 


•include -RTI.hh* 
•include ‘Arena. h* 
•include ‘npsGeometry . h* 
•include ‘bbKeyboard .h* 
•include <GL/gl.h> 
•include ‘admin. h‘ 
•include ‘amObject.h* 
•include ‘amHLAAdmin .h* 


virtual void sendlnteraction (RTI : :Fed«rationTime) . 


// Extent data memebers 


virtual void receivelnteraction ( RTI :: Interact lonClassHandle 
thelnteraction . 


char* Arena • :ms_ModuleName = ‘amArena*. 


const RTI : : ParameterHandleValuePai rSeti theParameters ); 

virtual void receivelnteraction (RTI - Interact lonClassHandle. 

RTI: : ParameterHandleValuePairSetS. . RTI: .FederationTime. 

RTI: : UserSuppliedTag ( ; 


' / 1 II / // // ///////// // Hill ,11111 / // // / / /////// '<'/!./// > > //>*'/ t at ' 

•/ Construction/Destruccion 

< tm n n ////// / nn / //// / / / tint t //// / //////// ////// / / inn. < / / // /// - 


virtual RTI- Boolean checkCol 1 is ion (amObject' that); 
virtual float checkTerrainCollision (amObject * that), 
virtual void deleteObject ( ) ; 


/ Function Name: Arena t RTI . . ObjectID id) 

/ Task constructor -- instance intializer 

II Return Value- void 


protected : 


Arena .Arena ( RTI : : ObjectID id) { 


RTI: : At t r ibut eHandle Va luePai rSet • CreateNVPSet ( ) . 

) ; 


cout « ‘Arena (Old)' << id << endl. 




setEntitylD(id) , 

npsVec3f xx,- 

XX. set (0. Of. 0. Of. 0. Of). 

setPosition (xx) , 
npsQuatemion yy,- 
setOnentation (yy) ; 




localFlag = RTI: :RTI_FALSE; 
updateFlag = RTI : ■ RTI.TRUE ; 




Admin: :ms_Terram = this; 
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*nd constructor 



.f (upd«t»-Flag) 



Function Name Arena t 

Task constructor - used for object storage m ModuleArray 
Return Value void 



RTI Attribut eHandleVa luePa 1 r Set * pNvpS^c JreateMVPSet ■ 

Admin oend&itltyUpdate ' gwtEntitylD I ‘pKvpSe: . getModuleName i 

updateFLag = RTI RTI.FALSE. 

/end if 



Ar*-na Arena 1 

end default •(..nstru'-’ or 



Function Name -Arena (j 
Task destructor 
Return Value void 



cout << ’The arena geometry was just deletedvn* 

<< *If you deleted the terrain ignore message in* 

<< 'else a federate just quit the f ederat ion \n* 

<< * PUSH T to display terrain* 

<< endl 

npsGeomecry* tmp = npsCeomecry f indObject ( *amArena_Geom* J . 
delete tmp. 



end destructor 



Function Name sendUpdates (RTI ObjectID old 
RTI At cnbut eHandleVa luePa irSet i ta. 

RTI FederationTime ft. RTI . : UserSuppliedTag tag: 

Task not implemented in this module -- pure virtual function must 
have definition 
Return Value void 



void Arena sendUpdates [ RTI ■ ObjectID oid. RTI . Attr ibuteHandleValuePairSetfc 

ta . 

RTI Federat lonTime ft. RTI • UserSuppliedTag tag) 



Function Name sendUpdates ( RTI :: FederationTime newTime) 

Task send handle value pair to rtx for update to federation 
Return Value: void 



void Arena sendUpdates (RTI . : FederationTime newTime) ( 



void Arena receivelnteract ion ( RTI :: Interact ionClassHandle ich. 

RTI : ParameterHandleValuePairSeti phvps. RTI . : Federac ionTime ft. 
RTI : : UserSuppliedTag tag) 

O 



Function Name receivelnteraction ; RTI : : Interactior.ClassHandle 
the Interact ion, 

// const RTI ParameterHandleValuePairSecfc theParameters ) 

// Task: not implemented m this module — pure virtual function must 

// have definition 
// Return Value void 



void Arena : receiveInteraction( RTI : : InteractionClassHandle thelnteraction . 

const RTI . ParameterHandleValuePairSetl. theParameters ) 

{)//end receivelnteraction 



// Function Name sendlnteraccion (RTI . : FederationTime ft) 

// Task: not implemented in this module -- pure virtual function must 

il have definition 
' Return Value void 



void Arena :: sendlnteraction (RTI : FederationTime ft) 

{) 



end s-ndUpdates 



Function Name receivf Updates [ RTI ObjectID Old. const 
RTI Attr lbuteHar.dleValuePairSett cheAttr ibutes 

RTI FederationTime theTime. RTI U«erSuppi ledTag theTag 
Task decodes HVP from RTI for this object 
Return Value void 



void Arena receive Updates ( RTI ObjectID oid. const 
RTI Attn but eHandleVa luePa irSetl. CheAttr ibutes 

RTI. FederationTime theTime. RTI UserSuppliedTag theTag ( 
RTI Attr lbuteHandle attrHandle. 
unsigned long vaiueLength. 

// We need to iterate through the AttnbuteHandleValuePairSet 
'/ to extract each Attr lbuteHandleValuePair Based on the type 
n specified i the value returned by getHandlei: ) we need Co 
/ extract Che data frlom the buffer that is returned by 

// getVaiuel! 

for ( unsigned int i - 0; i < cheAttr ibutes . size i / , i*« ) 

( 

attrHandle = theActr ibutes getHandle i ). 

if ( attrHandle Admin : getPositionActrHandle ( ) ) 

{ 

npsVeclf tmp. 

theActributes . getVa lue : i. (char *) temp . vaiueLength ). 
setPosition (tmp) . 

) / /end if 

)// end for 

)//end recevieUpdates 



// Function Name receivelnteraction (RTI : InteractionClassHandle ich. 
// RTI ParameterHandleValuePairSetl. phvps. RTI :: Federat ionTime ft. 

// RTI UserSuppliedTag tag) 

II Task not implemented in this module -- pure virtual function must 
// have definition 

II Return Value void 

// ***• 



// Make sure the RTI Ambassador is set . 
if ( Admin: :ms_rciAmb ) 

{ 

// - 

II Set up the data structure required to push this 
// objects’s state to Che RTI 

// 

RTI. ■. Obj eccIDcounc numAtcribuces (1) ; 

pArenaAt tributes = RTI : Attr ibuteSecFaccory :: create 1 numAtcributes }; 

pArenaAttnbutes->add( Admin: : getPositionAttrHandle ( ) . 

(char* i ^position, 
sizeof ( npsVec3 f ) ); 

) 

return pArenaAttributes. 

) //end CreateNVPSet ( ) 



II 

// Function Name display {) 

II Task: not implemented in this module -- pure virtual function muse 

// have definition 
II Return Value void 



void Arena :display{)( 
)// end display 



• Function Name sendlnteraction (RTI : Interact ionClassHandle lhc, 

'/ RTI : ParameterHandleValuePairSecfc phvps. RTI : FederationTime ft. 
RTI : : UserSuppl ledTag tag) 

Task not implemented in this module -- pure virtual function must 
have definition 
ll Return Value void 



II 

// Function Name createObject 'P.TI : :ObjectID old) 

/ Task: creates an object and returns a pointer to it 

// Return Value amObject* 



amObject* Arena : createObject (RTI ;. Object ID oid)( 



void Arena :: sendlnteraction (RTI ■: InteractionClassHandle ihc. 

RTI : : ParameterHandleValuePa lrSetfc phvps. RTI :: FederationTime ft, 
RTI . UserSuppliedTag tag) 

U 



Arena* tmpArena = new Arena (oid) ; 
return (amObject* ) tmpArena . 

)//end createObject 



// 

II Function Name. CreateNVPSet ( ) 

// Task. creates HVP sec pertinent to this object 
// Return Value: AttnbuteHandleValuePairSet * 



// 

II Function Name: getModuleName \ ) 

// Tasx: accessor method for module name 

// Return Value char* 

// 



RTI : AttnbuteHandleValuePairSet* Arena. : CreateNVPSet () { 

RTI :: AttnbuteHandleValuePairSet* pArenaActr ibutes s NULL; 



char* Arena ; ; getModuleName () { 
return Arena: : ms_ModuleName ; 
)// getModuleName 
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' . .iy 



rt: R-. 



ruac:;ori Name setLocalObj ect < RTI Boolean flag 
"Task sec the object as .oeal or not 
Return Value void 



void Arena setLocalObject (RTI Boolean f.ag 
1 oca 1 Flag flag. 

1 'end setEocalObject 



Function Name iOcalObject I 

Task accessor method for local object flag 
Return Value Boolean 



RTI Boolean Arena localObject >( 
return localFlag 
’ /end localObject 



Function Name isTerrain:! 

Task informs amHLAAdmm whether the object is a terrain object or not 
Return Value- Boolean 







‘ ag 



TR. * 

ing cheek 

that - >g»tPosi t . on 

r rt: rti.true 



North wall cnerfc 
else it' that - >getPositl. - .- 
i lag - RTI FTI.TRUE 



south Wall cneck 
else if{ that egetposi t lor. 1 
f.ag RTI PTI_TROE 



get 



2 4 Of 



20 3t 



W»st wall check 

else l t ( ( that • >get?osit ion ( i get 0) * 24 Of 

f.ag i RTI RTI_TRUE, 



, East wall check 

else if ( (that-'getPosidon ( . > get(3) > 24 0f)( 
flag i RTI RTI.TRUE, 



return flag. 

/end checkColl ision 



RTI.. Boolean Arena isTerrain 
return RTI RTI_TRUE. 

) ' 'end isTerrain 



Function Name checkTerra inCol 1 ision(amOb)ect* that; 

Task returns y value for terrain to provide rudimentary terrain 
collision detection 
• Return Value void 



Function Name setUpdaterlag I RTI Boolean flag 

Task sets update flag -- used in send updates to decide whether to 
transmit a HVF or not 
Return Value void 



float Arena checkT»rrainCoi 1 ision iamObj ecc • that 
float yPosition = 0.0, 

if , ;that->getPosition ( ) > . get • 1 < 0 S' ( 

yPosition -OS. 



void Arena set Update Flag (RTI Boolean fiagM 

updateFlag = flag. return yPosition. 

)//end setUpdatePlag 

)//end checkTerra inCollision 



Function Name checkCol 1 is ion ( amOb j ect * that) >' * 

Task returnds true if there is a collision with this object or not / Function Name deieteObject ( ) 
Return Value Boolean > ' Task remote delete function 
* ............ Return Value void 



RTI: Boolean Arena checkCollision (amObjecf that)( 

void Arena deieteObject 11 ( 

RTI . : Boolean flag = RTI RTI.FALSE. 

delete this, 

// floor ckeck 

if ( (that->getPosit ion ( ) ) . get 1 1 ) < 0 Sf){ 



This is the module.txt file for amPageModule module. 



amPageModule Files 



Bambool . Ob 
3 

bbKeyboardModule 

bbMouseModule 

npsVisualModule 



I 
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EXECUTIVE SUMMARY 

File Name module h 

Author CPT Stewart lilcs Naval Postgraduate School 

Description defines methods pertinen' tc module loading and un.oadmg 
September 1998. Masters Thesis 



•ifndef module 

•define module 



FUNCTION PROTOTYPE SPECIFICATIONS 



•itdef cplusplus 

extern ■ C * { 

•endi f 

ADM IN_API const char * get ModuleName ( i 
A DM I N_A P I float getModuleVer Sion 1 . 
ADKIN_API const char 'getModuleDate ( i 
ADM IN_API const char -getModuleText ( i 
ADMIN_API bool imtModuleO. 

ADM IN_API bool exitModule () . 

•ifdef cplusplus 

lendi f 

•endif // module 



EXECUTIVE SUMMARY 
File Name module c 

Author CPT Stewart Liles Nava. Postgraduate School 

Description defines methods pertinent to module loading and unloading 
September 199*. Masters Thesis 



INCLUDES AND EXTERNS 



•include "module h* 
•include "amPageModule h" 



CODE 



const char "getModuleName ( i 

{ 

return * amPageModule * . 

) 

float getModuleVersion O 

{ 

return 1.0. 

) 

const char "getModuleDate ( ) 

{ 

return "1998/09/01 06. OS <18*. 

) 

const char "getModuleText ) 

( 

return "This module enables the user to dynamically page modules in\n 

and out of the system via pressing the L and U keys respectively"; 

> 

bool initModule{) 

( 

imtamPageModule ( t . 
return 1. 

) 

bool exitModule U 

( 

return 1, 

) 



// 

// EXECUTIVE SUMMARY 

// 

// File Name-. amPageModule.h 

// 

// Author. CPT Stewart Liles. Naval postgraduate School 

// 

// Description: defines methods pertinent to module loading and unloading 

// 

// September 1998. Masters Thesis 

II 

•ifndef .amPageModule 
•define _amPageModule 



// 
// 
// 
// 
1 1 
n 
// 
u 
// 
// 
// 
// 
// 
// 



EXECUTIVE SUMMARY 
File Name amPageModule . c 

Author: CPT Stewart Liles, Naval Postgraduate School 
Description: defines methods pertinent to module loading and 
September 1998. Masters Thesis 

INCLUDES AND EXTERNS 



iloading 



FUNCTION PROTOTYPE SPECIFICATIONS 



void imtamPageModule ( ) ; 
•endif // _myKeyModule 



• include 
• include 
•include 
•include 
•include 
•include 
•include 
•include 



"amPageModule . h" 
"bbKeyboard .h" 
"bbEventResponse . h" 
"bbCallback h" 
"bbModule . h" 
"bbMouse h' 
■npsWmdow. h" 
"npsViewpor t . h" 



// 

/ / CODE 

// 

// 

// Function Name imtamPageModule ; i 

// Task: initialize Module -- this is run only once 

// sets up keyboard callbacks 
// Return Value, void 

// 



void imtamPageModule () ( 

void loadFunc (bbObject "object, bbData "data), 
void unloadFunc (bbObject "object. bbData "data). 

bbKeyboard "keyboard. 

bbEventResponse "eventResponse. 
bbCallback "callback. 



keyboard = bbKeyboard ; getlnstance () ; 

// load module key 

eventResponse = new bbEventResponse (bbKeyboard : KEY.L 
bbKeyboard : CTRL_KASK | bbKeyboard : DOWN_TRANS ) ; 
callback = new bbCallback!); 
callback->setFunc tloadFunc) . 
entResponse->addCallbackLast (callback) ; 
keyboard->add EventResponse | eventResponse ) . 

II unload module key 

eventResponse = new bbEventResponse (bbKeyboard • KEY.U | 
bbKeyboard: ;CTRL_MASK | bbKeyboard : DOWN .TRANS 1 . 
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Unable Ci - ad 



mo luleName 



callback .lew bbCallback 
ra 1 lback- »setFunc unloadFun. > 
evwtRespons'- »addCal ibackLast J callback 
keyboard- >add£ventResponse (eventResponse 

'end mitamPageModule 



endl 



_t , 'bbModule load imoduletJame 
cout << * myDynamicPageM:>dui.e 

cout << endl. 



Function Name loadFunc ( I 

Task callback function that loads modules 
Return Value void 



void loadFunc (bbObiect ‘object bbData ‘data . { 
mt mouselnWmdow ( i . 



- end i f 
end loadFunc 



Function Name loadFunc ) 

Task callback function that unloads modules 
Pe*urn Value void 



char moduleName [64 ] . 
char *ptr. 



-•id un loadFunc (bbObject ‘object, bbData ‘data 
mt mouse InWindow ' . 



if (mouse InWindow ) » { 



cout << ‘LOADPlease enter the module’s name * << flush, 
cm >> moduleName. 
cout << endl. 

if * strncmp (moduleName ‘http //*. 7)) { 

ptr = moduleName - 7. / t skip over http:// 

ptr = strrchriptr. // make sure url well formed 

if ( 'ptr) { 

cout << ‘ myDynamicPageModule Bad command line parameter 

endl . 

cout << * myDynamicPageModule URLs must be formatted as 
\‘http / /<host> [ /path] /moduleNameN * * << endl, 

cout << * myDynamicPageModule Example bamboo 
http • / /watsen net/Bamboo/Modules/myRemoteModule* << endl. 
cout << endl, 

) 

•ptr = ‘ \0 ' ; // efficient hack 

if ( *(ptr*l) == ’ \0 ’ ) ( // module can not be mdex.html' 



cout << * myDynamicPageModule Bad command line parameter * << 

endl . 

cout << ‘ myDynamicPageModule URLs must be formatted as 
\*http / /<host> [/path] /modul«Name\* * << endl. 

cout << * myDynamicPageModule Sample, bamboo 
http: / /wa tsen . net /Bamboo/Modules /myRemoteModule* << endl, 
cout << endl, 

) 

if {'bbModule load(ptr-l. moduleName | ) { 

‘ptr = */*. // put it back 

cout << * myDynamicPageModule Unable to load * << moduleName << 

endl ; 

cout << endl. 

) 

) 

else { // must already be on disk 



char moduleName (o4 , . 

bbModule ‘module. 

if (mouselnWmdowi |( 

cout << ‘UNLOAD Please enter the module's name * << flush, 
cm >> moduleName. 
cout << endl; 



module i bbModule : mdObj ect (moduleName . 
if ( ’module) ( 

cout << * myDynamicPageModule specified module ** << moduleName << 
not currently loaded, .ignoring* << endl. 
return. 



if (’.bbModule : unload (module )) { 

cout << * myDynamicPageModule Error unloading * << moduleName << 

endl . 

cout << ‘ Fatal Error - aborting executable’* << endl << endl, 
ex 1 1 ( 0 ) .- 

} 

) / / end i f 

i" / end unloadfunc 



Function Name mouselnWmdow ( ) 

Task tells if mouse is in the correct window to receive keyboard 
commands 

Return Value mt representing boolean 



int mouselnWmdow ( ) { 

mt flag - 0; 

npsWindow ‘window, 

npsViewport ‘viewport. 



window = npsWindow-. : f mdObj ect ( ‘AdmmWindoW } ; 
viewport = npsViewport. : findObject ( ‘AdmmViewport* ) ; 
float x.y, 

x = bbMouse :: getX () ; 
y - bbMouse . getY O : 
bbScreen -. : norma lizeVal ( 4.x, fcy) , 

if (window) ( 

if (viewport-xgetWmdow ( ) ->isValInside {x. y) ) { 
flag = 1, 

) 

) 



return flag; 














, 



APPENDIX C: GLOSSARY 



attribute 

• A named portion of an object state, 
event 

• A change of object attribute value, an interaction between objects, an 
instantiation of a new object, or a deletion of an existing object that is 
associated with a particular point on the federation time axis. Each event 
contains a time stamp indicating when it is said to occur (also see definition 
of message). 

federate 

• A member of a HLA Federation. All applications participating in a 
Federation are called Federates. In reality, this may include Federate 
Managers, data collectors, live entity surrogates simulations, or passive 
viewers. 

federation 

• A named set of interacting federates, a common federation object model, 
and supporting RTI, that are used as a whole to achieve some specific 
objective. 

federation execution 

• The federation execution represents the actual operation, over time, of a 
subset of the federates and the RTI initialization data taken from a 
particular federation. It is the step where the executable code is run to 
conduct the exercise and produce the data for the measures of effectiveness 
for the federation execution. 

Federation Object Model (FOM) 

• An identification of the essential classes of objects, object attributes, and 
object interactions that are supported by an HLA federation. In addition, 
optional classes of additional information may also be specified to achieve a 
more complete description of the federation structure and/or behavior. 

interaction 

• An explicit action taken by an object, that can optionally(within the bounds 
of the FOM) be directed toward other objects, including geographical 
areas, etc. 

message 

• A data unit transmitted between federates containing at most one event. 
Here, a message typically contains information concerning an event, and is 
used to notify another federate that the event has occurred. When 
containing such event information, the message's time stamp is defined as 
the time stamp of the event to which it corresponds. Here, a "message" 
corresponds to a single event, however the physical transport media may 
include several such messages in a single "physical message" that is 
transmitted through the network. 



• model 

• A physical, mathematical, or otherwise logical representation of a system, 
entity, phenomenon, or process. [DoD 5000.59] 

• object 

• A fundamental element of a conceptual representation for a federate that 
reflects the "real world" at levels of abstraction and resolution appropriate 
for federate interoperability. For any given value of time, the state of an 
object is defined as the enumeration of all its attribute values. 

• object model 

• A specification of the objects intrinsic to a given system, including a 
description of the object characteristics (attributes)and a description of the 
static and dynamic relationships that exist between objects. 

• object model framework 

• The rules and terminology used to describe HLA object models. 

• object ownership 

• Ownership of the ID attribute of an object, initially established by use of 
the Instantiate Object interface service. Encompasses the privilege of 
deleting the object using the Delete Object service. Can be transferred to 
another federate using the attribute ownership management services. 

• Runtime Infrastructure (RTI) 

• The general purpose distributed operating system software which provides 
the common interface services during the runtime of an HLA federation. 

• simulation 

• A method for implementing a model over time. Also, a technique for 
testing, analysis, or training in which real-world systems are used, or where 
real-world and conceptual systems are reproduced by a model. 

• Simulation Object Model (SOM) 

• A specification of the intrinsic capabilities that an individual simulation 
offers to federations. The standard format in which SOMs are expressed 
provides a means for federation developers to quickly determine the 
suitability of simulation systems to assume specific roles within a 
federation. 

• time management 

• A collection of mechanisms and services to control the advancement of 
time within each federate during an execution in a way that is consistent 
with federation requirements for message ordering and delivery. 
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